From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 1 09:25:48 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02428 for ; Wed, 1 Mar 2000 09:25:46 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8FA1A350@standards.nortelnetworks.com>; Wed, 1 Mar 2000 9:21:44 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 65490 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 09:20:10 -0500 Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F1AFA300@standards.nortelnetworks.com>; Wed, 1 Mar 2000 9:10:09 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id PAA13990; Wed, 1 Mar 2000 15:12:27 +0100 (MET) 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 PAA29069; Wed, 1 Mar 2000 15:12:25 +0100 (MET) Received: from ericsson.com (kipe102.eraj.ericsson.se [147.214.68.102]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id PAA16779; Wed, 1 Mar 2000 15:12:25 +0100 (MET) X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF208A3C@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38BD2545.C5F0C1FB@ericsson.com> Date: Wed, 1 Mar 2000 15:12:21 +0100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Updated ATM extensions for next meeting X-To: "Rosen, Brian" X-cc: Rajesh Kumar , ISC Device Control Work Group , atmsdp@eng.fore.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Tom, I thought at Washington that it was told to Megaco that this is a MMUSIC work item? Cheers, Christian "Rosen, Brian" wrote: > > I don't really care about this much, but Tom, could we be > considered a design team on this issue and "bless" it? > Of course we would have to have the whole group start > reviewing it soon, but we have quite a few Megaco folks on > this list, it was announced on the list, etc. > > Brian > > > -----Original Message----- > > From: Christian Groves [mailto:Christian.Groves@ericsson.com] > > Sent: Wednesday, March 01, 2000 4:05 AM > > To: Rajesh Kumar > > Cc: ISC Device Control Work Group; atmsdp@eng.fore.com > > Subject: Re: Updated ATM extensions for next meeting > > > > > > Hello Rajesh, > > > > I have one slight problem with the internet draft name. It is not an > > output of the MEGACO working group and thus should not have megaco in > > the title. Please change the name to represent its origin. > > > > Cheers, Christian > > > > Rajesh Kumar wrote: > > > > > > Here is the ATM extensions document to be reviewed > > tomorrow. It is the > > > same as the one I had emailed a few days back, with the > > exception that > > > an optional aggregation mode parameter has been added to the media > > > information line for data media (Section 3.8). Note that > > this document > > > also has QoS parameters in the SDP per the recommendation of the ISC > > > group. > > > > > > Also, I have extracted the SDP specific requirements for ATM > > > applications into an internet draft proposal. This is also included. > > > > > > Please review the attached documents and return your > > comments either > > > to Bill Foster or to me. > > > > > > Name: > > ATM_Extensions_xGCP_rev3.1_external_version.pdf > > > ATM_Extensions_xGCP_rev3.1_external_version.pdf Type: > > Acrobat (application/pdf) > > > Encoding: base64 > > > > > > Name: > > draft-ietf-megaco-sdp-atm-00.pdf > > > draft-ietf-megaco-sdp-atm-00.pdf Type: Acrobat > > (application/pdf) > > > Encoding: base64 > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 1 10:13:05 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04294 for ; Wed, 1 Mar 2000 10:13:01 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3C699B00@standards.nortelnetworks.com>; Wed, 1 Mar 2000 10:09:31 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 66188 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 10:08:23 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.14161E80@standards.nortelnetworks.com>; Wed, 1 Mar 2000 10:08:23 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 1 Mar 2000 09:09:06 -0600 Received: from zrchb213.us.nortel.com (actually zrchb213) by zmers013; Wed, 1 Mar 2000 10:08:52 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 1 Mar 2000 09:08:51 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8390.0D2856E0" Message-ID: <29400B68197CD31188830000F8CD15D343BC68@zcard00q.ca.nortel.com> Date: Wed, 1 Mar 2000 09:08:48 -0600 Reply-To: Peter Blatherwick Sender: "Media Gateway Control (megaco)" From: Peter Blatherwick Subject: I-D posted: Megaco IP Phone MG 02 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_01BF8390.0D2856E0 Content-Type: text/plain Greetings: An updated version of the Megaco IP Phone MG I-D has been submitted as: "draft-ietf-megaco-ipphone-02.txt". Updates include: - Alignment to latest reality, to track last call version of Megaco/H.248 and related package documents; - Removed user interface package specifics, now contained in separate documents; - Spelled out use of application-specific protocol profile more carefully. Now that Megaco/H.248 core protocol and package documents are wrapping up for last call, we hope we can bring some attention back to finalization of Megaco applications. This would include Megaco IP Phone MG, but would also hopefully include some others (for example Text Telephony, FAX/Modem, etc). Settling some specific applications would seem to be a very useful, even necessary, step towards interoperability testing and verification of the Megaco Protocol as normal next phases of the IETF process. Regards, Peter Blatherwick Bob Bell Phil Holland ------_=_NextPart_001_01BF8390.0D2856E0 Content-Type: text/html I-D posted: Megaco IP Phone MG 02

Greetings:

An updated version of the Megaco IP Phone MG I-D has been
submitted as: "draft-ietf-megaco-ipphone-02.txt".

Updates include:
- Alignment to latest reality, to track last call version of
  Megaco/H.248 and related package documents;
- Removed user interface package specifics, now contained in
  separate documents;
- Spelled out use of application-specific protocol profile more
  carefully.

Now that Megaco/H.248 core protocol and package documents are
wrapping up for last call, we hope we can bring some attention
back to finalization of Megaco applications.  This would include
Megaco IP Phone MG, but would also hopefully include some others
(for example Text Telephony, FAX/Modem, etc).  Settling some
specific applications would seem to be a very useful, even
necessary, step towards interoperability testing and verification
of the Megaco Protocol as normal next phases of the IETF process. 

Regards,
Peter Blatherwick
Bob Bell
Phil Holland

------_=_NextPart_001_01BF8390.0D2856E0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 1 10:28:04 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04809 for ; Wed, 1 Mar 2000 10:28:03 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.37E18FF0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 10:23:42 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 66332 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 10:23:15 -0500 Received: from smtprich.nortel.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.27C01380@standards.nortelnetworks.com>; Wed, 1 Mar 2000 10:23:15 -0500 Received: from zrchh190 by smtprich.nortel.com; Wed, 1 Mar 2000 09:26:11 -0600 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by zrchh190; Wed, 1 Mar 2000 09:06:58 -0600 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 1 Mar 2000 10:04:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF838F.789BBC9C" X-Orig: Message-ID: Date: Wed, 1 Mar 2000 10:04:40 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Updated ATM extensions for next meeting X-To: Christian Groves , "Rosen, Brian" X-cc: Rajesh Kumar , ISC Device Control Work Group , atmsdp@eng.fore.com, Joerg Ott To: MEGACO@STANDARDS.NORTELNETWORKS.COM ------_=_NextPart_001_01BF838F.789BBC9C Content-type: text/plain; charset="us-ascii" It took me a moment to figure out what you were concerned about: I did not announce the I-D which Rajesh had sent along with the main document, since the information was duplicated in the main document. You have a point: I think Joerg would claim final jurisdiction over changes to SDP on behalf of MMUSIC. If he does not, I am quite willing to ask the Megaco WG if they will accept it as a work item, because it is so important to Megaco deployment. Actually, in that latter case I would want the SDP changes embedded in a broader Megaco package definition so that we get the total picture of how ATM is specified between the MGC and MG. There has been an objection that this approach would require dismemberment of Annex C, but as far as I am concerned the Annex C encodings could simply be reproduced in the package definitions. Pending a declaration on Joerg's part that Megaco can do the work, I would suggest that the I-D be designated as an MMUSIC rather than a Megaco input. > -----Original Message----- > From: Christian Groves [SMTP:Christian.Groves@ericsson.com] > Sent: Wednesday, March 01, 2000 9:12 AM > To: Rosen, Brian > Cc: Rajesh Kumar; ISC Device Control Work Group; atmsdp@eng.fore.com; > ietf_megaco > Subject: Re: Updated ATM extensions for next meeting > > G'Day Tom, > > I thought at Washington that it was told to Megaco that this is a MMUSIC > work item? > > Cheers, Christian > > "Rosen, Brian" wrote: > > > > I don't really care about this much, but Tom, could we be > > considered a design team on this issue and "bless" it? > > Of course we would have to have the whole group start > > reviewing it soon, but we have quite a few Megaco folks on > > this list, it was announced on the list, etc. > > > > Brian > > > > > -----Original Message----- > > > From: Christian Groves [mailto:Christian.Groves@ericsson.com] > > > Sent: Wednesday, March 01, 2000 4:05 AM > > > To: Rajesh Kumar > > > Cc: ISC Device Control Work Group; atmsdp@eng.fore.com > > > Subject: Re: Updated ATM extensions for next meeting > > > > > > > > > Hello Rajesh, > > > > > > I have one slight problem with the internet draft name. It is not an > > > output of the MEGACO working group and thus should not have megaco in > > > the title. Please change the name to represent its origin. > > > > > > Cheers, Christian > > > > > > Rajesh Kumar wrote: > > > > > > > > Here is the ATM extensions document to be reviewed > > > tomorrow. It is the > > > > same as the one I had emailed a few days back, with the > > > exception that > > > > an optional aggregation mode parameter has been added to the media > > > > information line for data media (Section 3.8). Note that > > > this document > > > > also has QoS parameters in the SDP per the recommendation of the ISC > > > > group. > > > > > > > > Also, I have extracted the SDP specific requirements for ATM > > > > applications into an internet draft proposal. This is also included. > > > > > > > > Please review the attached documents and return your > > > comments either > > > > to Bill Foster or to me. > > > > > > > > Name: > > > ATM_Extensions_xGCP_rev3.1_external_version.pdf > > > > ATM_Extensions_xGCP_rev3.1_external_version.pdf Type: > > > Acrobat (application/pdf) > > > > Encoding: base64 > > > > > > > > Name: > > > draft-ietf-megaco-sdp-atm-00.pdf > > > > draft-ietf-megaco-sdp-atm-00.pdf Type: Acrobat > > > (application/pdf) > > > > Encoding: base64 > > > ------_=_NextPart_001_01BF838F.789BBC9C Content-type: text/html Content-Transfer-Encoding: quoted-printable RE: Updated ATM extensions for next meeting

It took me a moment = to figure out what you were concerned about: I did not announce the I-D = which Rajesh had sent along with the main document, since the = information was duplicated in the main document. 

You have a point: I = think Joerg would claim final jurisdiction over changes to SDP on = behalf of MMUSIC.  If he does not, I am quite willing to ask the = Megaco WG if they will accept it as a work item, because it is so = important to Megaco deployment.  Actually, in that latter case I = would want the SDP changes embedded in a broader Megaco package = definition so that we get the total picture of how ATM is specified = between the MGC and MG.  There has been an objection that this = approach would require dismemberment of Annex C, but as far as I am = concerned the Annex C encodings could simply be reproduced in the = package definitions.

Pending a = declaration on Joerg's part that Megaco can do the work, I would = suggest that the I-D be designated as an MMUSIC rather than a Megaco = input.

    -----Original Message-----
    From:   Christian Groves = [SMTP:Christian.Groves@ericsson.com]
    Sent:   Wednesday, March 01, 2000 9:12 AM
    To:     Rosen, Brian
    Cc:     Rajesh Kumar; ISC Device Control Work Group; = atmsdp@eng.fore.com; ietf_megaco
    Subject:       = Re: Updated ATM extensions for next = meeting

    G'Day Tom,

    I thought at Washington that it was = told to Megaco that this is a MMUSIC
    work item?

    Cheers, Christian

    "Rosen, Brian" wrote:
    >
    > I don't really care about this = much, but Tom, could we be
    > considered a design team on this = issue and "bless" it?
    > Of course we would have to have = the whole group start
    > reviewing it soon, but we have = quite a few Megaco folks on
    > this list, it was announced on = the list, etc.
    >
    > Brian
    >
    > > -----Original = Message-----
    > > From: Christian Groves = [mailto:Christian.Groves@er= icsson.com]
    > > Sent: Wednesday, March 01, = 2000 4:05 AM
    > > To: Rajesh Kumar
    > > Cc: ISC Device Control Work = Group; atmsdp@eng.fore.com
    > > Subject: Re: Updated ATM = extensions for next meeting
    > >
    > >
    > > Hello Rajesh,
    > >
    > > I have one slight problem = with the internet draft name. It is not an
    > > output of the MEGACO = working group and thus should not have megaco in
    > > the title. Please change = the name to represent its origin.
    > >
    > > Cheers, Christian
    > >
    > > Rajesh Kumar wrote:
    > > >
    > > > Here is the ATM = extensions document to be reviewed
    > > tomorrow. It is the
    > > > same as the one I had = emailed a few days back, with the
    > > exception that
    > > > an optional = aggregation mode parameter has been added to the media
    > > > information line for = data media (Section 3.8). Note that
    > > this document
    > > > also has QoS = parameters in the SDP per the recommendation of the ISC
    > > > group.
    > > >
    > > > Also, I have extracted = the SDP specific requirements for ATM
    > > > applications into an = internet draft proposal. This is also included.
    > > >
    > > > Please review the = attached documents  and return your
    > > comments either
    > > > to Bill Foster or to = me.
    > > >
    > > = >           &n= bsp;           &n= bsp;           &n= bsp;           &n= bsp;       Name:
    > > = ATM_Extensions_xGCP_rev3.1_external_version.pdf
    > > >    = ATM_Extensions_xGCP_rev3.1_external_version.pdf    = Type:
    > > Acrobat = (application/pdf)
    > > = >           &n= bsp;           &n= bsp;           &n= bsp;           &n= bsp;   Encoding: base64
    > > >
    > > = >           &n= bsp;           &n= bsp;           &n= bsp;    Name:
    > > = draft-ietf-megaco-sdp-atm-00.pdf
    > > >    = draft-ietf-megaco-sdp-atm-00.pdf    Type: Acrobat
    > > (application/pdf)
    > > = >           &n= bsp;           &n= bsp;            = Encoding: base64
    > >

------_=_NextPart_001_01BF838F.789BBC9C-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 1 10:34:05 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05124 for ; Wed, 1 Mar 2000 10:34:01 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8168A6E0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 10:25:46 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 66365 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 10:25:38 -0500 Received: from hoemlsrv.firewall.lucent.com (192.11.226.161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7CF2AF20@standards.nortelnetworks.com>; Wed, 1 Mar 2000 10:25:38 -0500 Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA17093 for ; Wed, 1 Mar 2000 10:29:09 -0500 (EST) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA17079 for ; Wed, 1 Mar 2000 10:29:08 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA09511; Wed, 1 Mar 2000 16:29:07 +0100 (MET) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA09419; Wed, 1 Mar 2000 16:28:46 +0100 (MET) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Original-CC: megaco@standards.nortelnetworks.com, Joerg Ott References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38BD3731.AA76F5DD@lucent.com> Date: Wed, 1 Mar 2000 16:28:49 +0100 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: Updated ATM extensions for next meeting X-To: Tom-PT Taylor X-cc: Joerg Ott To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Tom, In my opinion it makes more sense to make this a mmusic work item than a megaco work item. Let's wait until we hear from mmusic before progressing the work in megaco: if mmusic accepts the work item, the mmusicians should be aware of the work going on on the ATM-SDP list that Brian set up. Cheers, John > Tom-PT Taylor wrote: > > It took me a moment to figure out what you were concerned about: I did > not announce the I-D which Rajesh had sent along with the main > document, since the information was duplicated in the main document. > > You have a point: I think Joerg would claim final jurisdiction over > changes to SDP on behalf of MMUSIC. If he does not, I am quite > willing to ask the Megaco WG if they will accept it as a work item, > because it is so important to Megaco deployment. Actually, in that > latter case I would want the SDP changes embedded in a broader Megaco > package definition so that we get the total picture of how ATM is > specified between the MGC and MG. There has been an objection that > this approach would require dismemberment of Annex C, but as far as I > am concerned the Annex C encodings could simply be reproduced in the > package definitions. > > Pending a declaration on Joerg's part that Megaco can do the work, I > would suggest that the I-D be designated as an MMUSIC rather than a > Megaco input. > > -----Original Message----- > From: Christian Groves [SMTP:Christian.Groves@ericsson.com] > Sent: Wednesday, March 01, 2000 9:12 AM > To: Rosen, Brian > Cc: Rajesh Kumar; ISC Device Control Work Group; > atmsdp@eng.fore.com; ietf_megaco > Subject: Re: Updated ATM extensions for next meeting > > G'Day Tom, > > I thought at Washington that it was told to Megaco that this is a > MMUSIC > work item? > > Cheers, Christian > > "Rosen, Brian" wrote: > > > > I don't really care about this much, but Tom, could we be > > considered a design team on this issue and "bless" it? > > Of course we would have to have the whole group start > > reviewing it soon, but we have quite a few Megaco folks on > > this list, it was announced on the list, etc. > > > > Brian > > > > > -----Original Message----- > > > From: Christian Groves [mailto:Christian.Groves@ericsson.com] > > > > Sent: Wednesday, March 01, 2000 4:05 AM > > > To: Rajesh Kumar > > > Cc: ISC Device Control Work Group; atmsdp@eng.fore.com > > > Subject: Re: Updated ATM extensions for next meeting > > > > > > > > > Hello Rajesh, > > > > > > I have one slight problem with the internet draft name. It is > not an > > > output of the MEGACO working group and thus should not have > megaco in > > > the title. Please change the name to represent its origin. > > > > > > Cheers, Christian > > > > > > Rajesh Kumar wrote: > > > > > > > > Here is the ATM extensions document to be reviewed > > > tomorrow. It is the > > > > same as the one I had emailed a few days back, with the > > > exception that > > > > an optional aggregation mode parameter has been added to > the media > > > > information line for data media (Section 3.8). Note that > > > this document > > > > also has QoS parameters in the SDP per the recommendation > of the ISC > > > > group. > > > > > > > > Also, I have extracted the SDP specific requirements for > ATM > > > > applications into an internet draft proposal. This is also > included. > > > > > > > > Please review the attached documents and return your > > > comments either > > > > to Bill Foster or to me. > > > > > > > > Name: > > > > ATM_Extensions_xGCP_rev3.1_external_version.pdf > > > > ATM_Extensions_xGCP_rev3.1_external_version.pdf Type: > > > > Acrobat (application/pdf) > > > > Encoding: > base64 > > > > > > > > Name: > > > draft-ietf-megaco-sdp-atm-00.pdf > > > > draft-ietf-megaco-sdp-atm-00.pdf Type: Acrobat > > > (application/pdf) > > > > Encoding: base64 > > > -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 1 11:19:40 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06717 for ; Wed, 1 Mar 2000 11:19:36 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.71D75850@standards.nortelnetworks.com>; Wed, 1 Mar 2000 11:15:26 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 66892 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 11:15:05 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.64FD3EB0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 11:15:04 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 1 Mar 2000 10:16:42 -0600 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by zmers013; Wed, 1 Mar 2000 11:16:04 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 1 Mar 2000 11:16:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8399.70487F1C" Message-ID: Date: Wed, 1 Mar 2000 11:15:53 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: I-D posted: Megaco IP Phone MG 02 X-To: Peter Blatherwick 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_01BF8399.70487F1C Content-Type: text/plain This document has been posted on the Megaco FTP site, at ftp://standards.nortelnetworks.com/megaco/docs/Adelaide2000/ and ftp://standards.nortelnetworks.com/megaco/docs/latest/ > -----Original Message----- > From: Blatherwick, Peter [CAR:AT14:EXCH] > Sent: Wednesday, March 01, 2000 10:09 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: I-D posted: Megaco IP Phone MG 02 > > Greetings: > > An updated version of the Megaco IP Phone MG I-D has been > submitted as: "draft-ietf-megaco-ipphone-02.txt". > > Updates include: > - Alignment to latest reality, to track last call version of > Megaco/H.248 and related package documents; > - Removed user interface package specifics, now contained in > separate documents; > - Spelled out use of application-specific protocol profile more > carefully. > > Now that Megaco/H.248 core protocol and package documents are > wrapping up for last call, we hope we can bring some attention > back to finalization of Megaco applications. This would include > Megaco IP Phone MG, but would also hopefully include some others > (for example Text Telephony, FAX/Modem, etc). Settling some > specific applications would seem to be a very useful, even > necessary, step towards interoperability testing and verification > of the Megaco Protocol as normal next phases of the IETF process. > > Regards, > Peter Blatherwick > Bob Bell > Phil Holland > ------_=_NextPart_001_01BF8399.70487F1C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D posted: Megaco IP Phone MG 02

This document has = been posted on the Megaco FTP site, at
ftp://standards.nortelnetworks.com/megaco/docs/Adelaid= e2000/ = and
ftp://standards.nortelnetworks.com/megaco/docs/latest/=

    -----Original Message-----
    From:   Blatherwick, Peter [CAR:AT14:EXCH]
    Sent:   Wednesday, March 01, 2000 10:09 AM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = I-D posted: Megaco IP Phone MG = 02

    Greetings: =

    An updated version of the Megaco IP = Phone MG I-D has been
    submitted as: = "draft-ietf-megaco-ipphone-02.txt".

    Updates include:
    - Alignment to latest reality, to = track last call version of
    =A0 Megaco/H.248 and related package = documents;
    - Removed user interface package = specifics, now contained in
    =A0 separate documents;
    - Spelled out use of application-specific = protocol profile more
    =A0 carefully.=20

    Now that Megaco/H.248 core protocol = and package documents are
    wrapping up for last call, we hope we can = bring some attention
    back to finalization of Megaco = applications.=A0 This would include
    Megaco IP Phone MG, but would also = hopefully include some others
    (for example Text Telephony, FAX/Modem, = etc).=A0 Settling some
    specific applications would seem to be a = very useful, even
    necessary, step towards interoperability = testing and verification
    of the Megaco Protocol as normal next = phases of the IETF process.=A0=20

    Regards,
    Peter Blatherwick
    Bob Bell
    Phil Holland

------_=_NextPart_001_01BF8399.70487F1C-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 1 11:23:11 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06761 for ; Wed, 1 Mar 2000 11:23:09 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BA880C70@standards.nortelnetworks.com>; Wed, 1 Mar 2000 11:17:28 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 66809 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 11:16:34 -0500 Received: from kickme.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.34A93990@standards.nortelnetworks.com>; Wed, 1 Mar 2000 11:06:34 -0500 Received: from rhino (rhino.cisco.com [172.20.9.57]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id HAA06388; Wed, 1 Mar 2000 07:58:25 -0800 (PST) Received: from p7020-img-nt (sj-dial-1-172.cisco.com [171.68.179.173]) by rhino (SMI-8.6/CISCO.WS.1.1) with SMTP id IAA28894; Wed, 1 Mar 2000 08:14:04 -0800 X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <4.1.20000301070630.00ac33c0@flipper.cisco.com> Date: Wed, 1 Mar 2000 08:06:47 -0800 Reply-To: Fred Baker Sender: "Media Gateway Control (megaco)" From: Fred Baker Subject: H.248 Activity X-To: taylor@NORTELNETWORKS.COM X-cc: pierre-andre.probst@swisscom.com, Scott_Bradner To: MEGACO@STANDARDS.NORTELNETWORKS.COM Tom: I'm writing to apologize on two points. First, I am told that I misunderstand ITU procedure, and therefore in questioning your procedure with respect to this document I incorrectly stated that you were in violation of it. You apparently were not; I am therefore sorry for that statement. The fact that ITU procedure allows a document being co-developed by the IETF's review procedures to be changed and decided without IETF last call or IESG review of the document or the changes underscores my other procedural concern, and Greg's concern that the procedures for co-developing documents need to be better spelled out earlier in the game. As he says, that is a lesson for us to learn. Second, it would have been far better for me to address you privately rather than state my concerns publicly in front of the working group. This no doubt caused you more embarrassment than I intended, and I am sorry for that procedure on my part. Fred Baker From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 1 14:08:14 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10734 for ; Wed, 1 Mar 2000 14:08:13 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.04516510@standards.nortelnetworks.com>; Wed, 1 Mar 2000 14:04:10 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 67412 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 14:02:52 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6F6F5700@standards.nortelnetworks.com>; Wed, 1 Mar 2000 13:52:51 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id NAA02412; Wed, 1 Mar 2000 13:55:33 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id NAA23257; Wed, 1 Mar 2000 13:55:29 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id <1WCMD6FK>; Wed, 1 Mar 2000 13:51:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF83AF.2987380A" Message-ID: <4FBEA8857476D311A03300204840E1CF208A3F@whq-msgusr-02.fore.com> Date: Wed, 1 Mar 2000 13:55:16 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Updated ATM extensions for next meeting X-To: Tom-PT Taylor X-cc: Joerg Ott 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_01BF83AF.2987380A Content-Type: text/plain; charset="iso-8859-1" This work has several components: Some SDP extensions (which are just registrations of new tags, rather than any change to SDP as far as I know) A Megaco package A MGCP package If I'm right about the SDP stuff, it doesn't need any official action from MMUSIC, but I'm happy to work through them if they wish to. The Megaco package part needs to be published, and at the moment, I'd prefer it be Megaco. I think it properly belongs in Megaco, but I don't really care. Brian -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Wednesday, March 01, 2000 10:05 AM To: MEGACO@standards.nortelnetworks.com Subject: Re: Updated ATM extensions for next meeting It took me a moment to figure out what you were concerned about: I did not announce the I-D which Rajesh had sent along with the main document, since the information was duplicated in the main document. You have a point: I think Joerg would claim final jurisdiction over changes to SDP on behalf of MMUSIC. If he does not, I am quite willing to ask the Megaco WG if they will accept it as a work item, because it is so important to Megaco deployment. Actually, in that latter case I would want the SDP changes embedded in a broader Megaco package definition so that we get the total picture of how ATM is specified between the MGC and MG. There has been an objection that this approach would require dismemberment of Annex C, but as far as I am concerned the Annex C encodings could simply be reproduced in the package definitions. Pending a declaration on Joerg's part that Megaco can do the work, I would suggest that the I-D be designated as an MMUSIC rather than a Megaco input. -----Original Message----- From: Christian Groves [SMTP:Christian.Groves@ericsson.com] Sent: Wednesday, March 01, 2000 9:12 AM To: Rosen, Brian Cc: Rajesh Kumar; ISC Device Control Work Group; atmsdp@eng.fore.com; ietf_megaco Subject: Re: Updated ATM extensions for next meeting G'Day Tom, I thought at Washington that it was told to Megaco that this is a MMUSIC work item? Cheers, Christian "Rosen, Brian" wrote: > > I don't really care about this much, but Tom, could we be > considered a design team on this issue and "bless" it? > Of course we would have to have the whole group start > reviewing it soon, but we have quite a few Megaco folks on > this list, it was announced on the list, etc. > > Brian > > > -----Original Message----- > > From: Christian Groves [ mailto:Christian.Groves@ericsson.com ] > > Sent: Wednesday, March 01, 2000 4:05 AM > > To: Rajesh Kumar > > Cc: ISC Device Control Work Group; atmsdp@eng.fore.com > > Subject: Re: Updated ATM extensions for next meeting > > > > > > Hello Rajesh, > > > > I have one slight problem with the internet draft name. It is not an > > output of the MEGACO working group and thus should not have megaco in > > the title. Please change the name to represent its origin. > > > > Cheers, Christian > > > > Rajesh Kumar wrote: > > > > > > Here is the ATM extensions document to be reviewed > > tomorrow. It is the > > > same as the one I had emailed a few days back, with the > > exception that > > > an optional aggregation mode parameter has been added to the media > > > information line for data media (Section 3.8). Note that > > this document > > > also has QoS parameters in the SDP per the recommendation of the ISC > > > group. > > > > > > Also, I have extracted the SDP specific requirements for ATM > > > applications into an internet draft proposal. This is also included. > > > > > > Please review the attached documents and return your > > comments either > > > to Bill Foster or to me. > > > > > > Name: > > ATM_Extensions_xGCP_rev3.1_external_version.pdf > > > ATM_Extensions_xGCP_rev3.1_external_version.pdf Type: > > Acrobat (application/pdf) > > > Encoding: base64 > > > > > > Name: > > draft-ietf-megaco-sdp-atm-00.pdf > > > draft-ietf-megaco-sdp-atm-00.pdf Type: Acrobat > > (application/pdf) > > > Encoding: base64 > > ------_=_NextPart_001_01BF83AF.2987380A Content-Type: text/html; charset="iso-8859-1" RE: Updated ATM extensions for next meeting
This work has several components:
    Some SDP extensions (which are just registrations of new tags, rather than
        any change to SDP as far as I know)
    A Megaco package
    A MGCP package
If I'm right about the SDP stuff, it doesn't need any official action from MMUSIC,
but I'm happy to work through them if they wish to.
 
The Megaco package part needs to be published, and at the moment, I'd prefer it
be Megaco.
 
I think it properly belongs in Megaco, but I don't really care.
 
Brian
-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Wednesday, March 01, 2000 10:05 AM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: Updated ATM extensions for next meeting

It took me a moment to figure out what you were concerned about: I did not announce the I-D which Rajesh had sent along with the main document, since the information was duplicated in the main document. 

You have a point: I think Joerg would claim final jurisdiction over changes to SDP on behalf of MMUSIC.  If he does not, I am quite willing to ask the Megaco WG if they will accept it as a work item, because it is so important to Megaco deployment.  Actually, in that latter case I would want the SDP changes embedded in a broader Megaco package definition so that we get the total picture of how ATM is specified between the MGC and MG.  There has been an objection that this approach would require dismemberment of Annex C, but as far as I am concerned the Annex C encodings could simply be reproduced in the package definitions.

Pending a declaration on Joerg's part that Megaco can do the work, I would suggest that the I-D be designated as an MMUSIC rather than a Megaco input.

    -----Original Message-----
    From:   Christian Groves [SMTP:Christian.Groves@ericsson.com]
    Sent:   Wednesday, March 01, 2000 9:12 AM
    To:     Rosen, Brian
    Cc:     Rajesh Kumar; ISC Device Control Work Group; atmsdp@eng.fore.com; ietf_megaco
    Subject:        Re: Updated ATM extensions for next meeting

    G'Day Tom,

    I thought at Washington that it was told to Megaco that this is a MMUSIC
    work item?

    Cheers, Christian

    "Rosen, Brian" wrote:
    >
    > I don't really care about this much, but Tom, could we be
    > considered a design team on this issue and "bless" it?
    > Of course we would have to have the whole group start
    > reviewing it soon, but we have quite a few Megaco folks on
    > this list, it was announced on the list, etc.
    >
    > Brian
    >
    > > -----Original Message-----
    > > From: Christian Groves [mailto:Christian.Groves@ericsson.com]
    > > Sent: Wednesday, March 01, 2000 4:05 AM
    > > To: Rajesh Kumar
    > > Cc: ISC Device Control Work Group; atmsdp@eng.fore.com
    > > Subject: Re: Updated ATM extensions for next meeting
    > >
    > >
    > > Hello Rajesh,
    > >
    > > I have one slight problem with the internet draft name. It is not an
    > > output of the MEGACO working group and thus should not have megaco in
    > > the title. Please change the name to represent its origin.
    > >
    > > Cheers, Christian
    > >
    > > Rajesh Kumar wrote:
    > > >
    > > > Here is the ATM extensions document to be reviewed
    > > tomorrow. It is the
    > > > same as the one I had emailed a few days back, with the
    > > exception that
    > > > an optional aggregation mode parameter has been added to the media
    > > > information line for data media (Section 3.8). Note that
    > > this document
    > > > also has QoS parameters in the SDP per the recommendation of the ISC
    > > > group.
    > > >
    > > > Also, I have extracted the SDP specific requirements for ATM
    > > > applications into an internet draft proposal. This is also included.
    > > >
    > > > Please review the attached documents  and return your
    > > comments either
    > > > to Bill Foster or to me.
    > > >
    > > >                                                       Name:
    > > ATM_Extensions_xGCP_rev3.1_external_version.pdf
    > > >    ATM_Extensions_xGCP_rev3.1_external_version.pdf    Type:
    > > Acrobat (application/pdf)
    > > >                                                   Encoding: base64
    > > >
    > > >                                        Name:
    > > draft-ietf-megaco-sdp-atm-00.pdf
    > > >    draft-ietf-megaco-sdp-atm-00.pdf    Type: Acrobat
    > > (application/pdf)
    > > >                                    Encoding: base64
    > >

------_=_NextPart_001_01BF83AF.2987380A-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 1 16:04:02 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13101 for ; Wed, 1 Mar 2000 16:04:01 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2473C350@standards.nortelnetworks.com>; Wed, 1 Mar 2000 15:59:36 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 67739 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 15:59:30 -0500 Received: from ns-inetext.inet.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.20F0DE20@standards.nortelnetworks.com>; Wed, 1 Mar 2000 15:59:30 -0500 Received: from harpo.inetint.com (harpo [172.16.99.60]) by ns-inetext.inet.com (8.9.2/8.9.2) with ESMTP id PAA02066 for ; Wed, 1 Mar 2000 15:01:45 -0600 (CST) Received: from inet.com ([172.16.63.49]) by harpo.inetint.com (Netscape Messaging Server 3.6) with ESMTP id AAA6DBF for ; Wed, 1 Mar 2000 15:07:12 -0600 X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF32E9FC@whq-msgusr-02.fore.com> <38BD2E56.5662E965@inet.com> <38BD848F.8603ADE8@inet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38BD8565.CFE35C31@inet.com> Date: Wed, 1 Mar 2000 15:02:29 -0600 Reply-To: Mart Nurmet Sender: "Media Gateway Control (megaco)" From: Mart Nurmet Organization: Inet - Product Line Management Subject: FWD: Information request! (Billing Package?) To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Mart Nurmet wrote: > More correspondence on billing. -Mart > > Nathan Nelson wrote: > > > The point that was being asked is not specific to MEGACO, but more general to a > decomposed architectures. > > > > The current formats that are used to bill PSTN traffic are based on AMA BAF or a > > carrier/vendor defined CDR. Inet believes there is a need to build a standard > > format for a Transaction over IP record that allows for elements and > > parameters to be recorded. > > > > Some of the key components of this record could be: > > > > A Tracking field to tie multiple records from multiple platforms together > > Time Stamps > > Usage Stamps > > Originating Information (PSTN Number, IP address, email address.....) > > Terminating Information (PSTN Number, IP address, email address....) > > Terminating Port/ Media Gateway > > Originating Port/Media Gateway > > Amount of bandwidth used > > Types of Applications used > > Premiums associated with Applications > > Application Information (Application server IP addresses) > > Intermediate network usage > > > > One of the basic issues with a decomposed architecture from an accounting aspect > > is that multiple devices are involved in call set, routing, application usage, > > signaling, and finally termination. It would be nice to see IETF support a > > group that looks at accountability and billing, or at least provide a basic > > model to build such records. > > > > Thx, > > Nate Nelson > > Inet > > > > "Rosen, Brian" wrote: > > > > > Interesting, I assumed everything EXCEPT a gateway throws CDRs. > > > Assuming a decomposed gateway, the GW feeds statistics to a Call Agent > > > (which would be a SIP UA among other things) that throws CDRs. > > > > > > The billing system collates all the CDRs. > > > > > > The spec required is, of course, the format of the CDR and the way they > > > are transported. You could claim that a "transaction log" is a form of > > > CDR I suppose. > > > > > > I'd certainly agree that SIP itself doesn't have any "billing package". > > > A UA and a server might, but that is independent of the protocol. Billing > > > might very well impact some things in SIP. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Dean Willis [mailto:dean.willis@wcom.com] > > > > Sent: Tuesday, February 29, 2000 2:41 PM > > > > To: Mart Nurmet; sip@lists.research.bell-labs.com > > > > Subject: RE: Information request! (Billing Package?) > > > > > > > > > > > > What would a billing package look like? I've never really understood the > > > > concept, and it might be useful to talk about it some more. > > > > > > > > Here's how some implementors are doing it: > > > > > > > > 1) Gateways throw CDRs using RADIUS or something similar. > > > > This feeds into rating, reporting, and billing systems, > > > > > > > > 2) SIP servers record transaction logs. These may feed into rating and > > > > billing systems, and probably feed into reporting systems. > > > > > > > > 3) QoS PEP and PDPs log resource usages. These feed upstream as well. > > > > > > > > 4) Other systems, like profile managers, report usage. > > > > > > > > 5) Rating, reporting, and billing systems sift thru the vast amounts of > > > > information coming at them and make useful things happen. > > > > > > > > All of these things use other protocols and systems -- they aren't SIP > > > > specific. They do rely on SIP functions like authentication > > > > -- that is, the goal of achieving billing functions has driven some > > > > requirements into the design of SIP. However, other than driving some > > requirements > > > > to SIP, such efforts are generally considered to be outside the scope of > > > > the SIP WG. > > > > > > > > Are you perhaps proposing to add functionality to SIP to simplify or enhance > > > > > > reporting capabilities or to simplify the task of driving downstream billing > > > > > > systems? > > > > > > > > -- > > > > Dena > > > > > -----Original Message----- > > > > > From: owner-sip@lists.research.bell-labs.com > > > > > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of > > > > Mart Nurmet > > > > > Sent: Monday, February 28, 2000 2:24 PM > > > > > To: sip@lists.research.bell-labs.com > > > > > Subject: Information request! (Billing Package?) > > > > > > > > > > > > > > > I am looking for information if there has been any work > > > > done to generate a > > > > > billing package for SIP. From my look at the available > > > > > information there does > > > > > not seem to be any. Is that the case or am I missing something? > > > > > > > > > > Thank you, > > > > > -Mart > > > > > > > > > > > > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 1 16:23:49 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13513 for ; Wed, 1 Mar 2000 16:23:48 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F632E9F0@standards.nortelnetworks.com>; Wed, 1 Mar 2000 16:19:47 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 67878 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 1 Mar 2000 16:18:34 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CA689630@standards.nortelnetworks.com>; Wed, 1 Mar 2000 16:18:33 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 1 Mar 2000 15:21:26 -0600 Received: from zrchb213.us.nortel.com (actually zrchb213) by zmers013; Wed, 1 Mar 2000 16:20:36 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 1 Mar 2000 15:20:33 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF83C3.F9F64170" Message-ID: Date: Wed, 1 Mar 2000 15:20:25 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Information request! (Billing Package?) X-To: Mart Nurmet 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_01BF83C3.F9F64170 Content-Type: text/plain; charset="iso-8859-1" I know of at least two standards in this area already (TIPHON OSP and H.323 Annex G), aside from the abortive VON MOU effort. Do we really need another one? > -----Original Message----- > From: Mart Nurmet [SMTP:mart.nurmet@INET.COM] > Sent: Wednesday, March 01, 2000 4:02 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: FWD: Information request! (Billing Package?) > > Mart Nurmet wrote: > > > More correspondence on billing. -Mart > > > > Nathan Nelson wrote: > > > > > The point that was being asked is not specific to MEGACO, but more > general to a > > decomposed architectures. > > > > > > The current formats that are used to bill PSTN traffic are based on > AMA BAF or a > > > carrier/vendor defined CDR. Inet believes there is a need to build a > standard > > > format for a Transaction over IP record that allows for elements and > > > parameters to be recorded. > > > > > > Some of the key components of this record could be: > > > > > > A Tracking field to tie multiple records from multiple platforms > together > > > Time Stamps > > > Usage Stamps > > > Originating Information (PSTN Number, IP address, email > address.....) > > > Terminating Information (PSTN Number, IP address, email > address....) > > > Terminating Port/ Media Gateway > > > Originating Port/Media Gateway > > > Amount of bandwidth used > > > Types of Applications used > > > Premiums associated with Applications > > > Application Information (Application server IP addresses) > > > Intermediate network usage > > > > > > One of the basic issues with a decomposed architecture from an > accounting aspect > > > is that multiple devices are involved in call set, routing, > application usage, > > > signaling, and finally termination. It would be nice to see IETF > support a > > > group that looks at accountability and billing, or at least provide a > basic > > > model to build such records. > > > > > > Thx, > > > Nate Nelson > > > Inet > > > > > > "Rosen, Brian" wrote: > > > > > > > Interesting, I assumed everything EXCEPT a gateway throws CDRs. > > > > Assuming a decomposed gateway, the GW feeds statistics to a Call > Agent > > > > (which would be a SIP UA among other things) that throws CDRs. > > > > > > > > The billing system collates all the CDRs. > > > > > > > > The spec required is, of course, the format of the CDR and the way > they > > > > are transported. You could claim that a "transaction log" is a form > of > > > > CDR I suppose. > > > > > > > > I'd certainly agree that SIP itself doesn't have any "billing > package". > > > > A UA and a server might, but that is independent of the protocol. > Billing > > > > might very well impact some things in SIP. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Dean Willis [mailto:dean.willis@wcom.com] > > > > > Sent: Tuesday, February 29, 2000 2:41 PM > > > > > To: Mart Nurmet; sip@lists.research.bell-labs.com > > > > > Subject: RE: Information request! (Billing Package?) > > > > > > > > > > > > > > > What would a billing package look like? I've never really > understood the > > > > > concept, and it might be useful to talk about it some more. > > > > > > > > > > Here's how some implementors are doing it: > > > > > > > > > > 1) Gateways throw CDRs using RADIUS or something similar. > > > > > This feeds into rating, reporting, and billing systems, > > > > > > > > > > 2) SIP servers record transaction logs. These may feed into rating > and > > > > > billing systems, and probably feed into reporting systems. > > > > > > > > > > 3) QoS PEP and PDPs log resource usages. These feed upstream as > well. > > > > > > > > > > 4) Other systems, like profile managers, report usage. > > > > > > > > > > 5) Rating, reporting, and billing systems sift thru the vast > amounts of > > > > > information coming at them and make useful things happen. > > > > > > > > > > All of these things use other protocols and systems -- they aren't > SIP > > > > > specific. They do rely on SIP functions like authentication > > > > > -- that is, the goal of achieving billing functions has driven > some > > > > > requirements into the design of SIP. However, other than driving > some > > > requirements > > > > > to SIP, such efforts are generally considered to be outside the > scope of > > > > > the SIP WG. > > > > > > > > > > Are you perhaps proposing to add functionality to SIP to simplify > or enhance > > > > > > > > reporting capabilities or to simplify the task of driving > downstream billing > > > > > > > > systems? > > > > > > > > > > -- > > > > > Dena > > > > > > -----Original Message----- > > > > > > From: owner-sip@lists.research.bell-labs.com > > > > > > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of > > > > > Mart Nurmet > > > > > > Sent: Monday, February 28, 2000 2:24 PM > > > > > > To: sip@lists.research.bell-labs.com > > > > > > Subject: Information request! (Billing Package?) > > > > > > > > > > > > > > > > > > I am looking for information if there has been any work > > > > > done to generate a > > > > > > billing package for SIP. From my look at the available > > > > > > information there does > > > > > > not seem to be any. Is that the case or am I missing something? > > > > > > > > > > > > Thank you, > > > > > > -Mart > > > > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01BF83C3.F9F64170 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Information request! (Billing Package?)

I know of at least = two standards in this area already (TIPHON OSP and H.323 Annex G), = aside from the abortive VON MOU effort.  Do we really need another = one?

    -----Original Message-----
    From:   Mart Nurmet [SMTP:mart.nurmet@INET.COM]
    Sent:   Wednesday, March 01, 2000 4:02 PM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = FWD: Information request! (Billing = Package?)

    Mart Nurmet wrote:

    > More correspondence on = billing.  -Mart
    >
    > Nathan Nelson wrote:
    >
    > > The point that was being = asked is not specific to MEGACO, but more general to a
    > decomposed architectures.
    > >
    > > The current formats that = are used to bill PSTN traffic are based on AMA BAF or a
    > > carrier/vendor defined = CDR.  Inet believes there is a need to build a standard
    > > format for a Transaction = over IP record that allows for elements and
    > > parameters to be = recorded.
    > >
    > > Some of the key components = of this record could be:
    > >
    > >     A = Tracking field to tie multiple records from multiple platforms = together
    > >     = Time Stamps
    > >     = Usage Stamps
    > >     = Originating Information (PSTN Number, IP address, email = address.....)
    > >     = Terminating Information (PSTN Number, IP address, email = address....)
    > >     = Terminating Port/ Media Gateway
    > >     = Originating Port/Media Gateway
    > >     = Amount of bandwidth used
    > >     = Types of Applications used
    > >     = Premiums associated with Applications
    > >     = Application Information (Application server IP addresses)
    > >     = Intermediate network usage
    > >
    > > One of the basic issues = with a decomposed architecture from an accounting aspect
    > > is that multiple devices = are involved in call set, routing, application usage,
    > > signaling, and finally = termination.  It would be nice to see IETF support a
    > > group that looks at = accountability and billing, or at least provide a basic
    > > model to build such = records.
    > >
    > > Thx,
    > > Nate Nelson
    > > Inet
    > >
    > > "Rosen, Brian" = wrote:
    > >
    > > > Interesting, I assumed = everything EXCEPT a gateway throws CDRs.
    > > > Assuming a decomposed = gateway, the GW feeds statistics to a Call Agent
    > > > (which would be a SIP = UA among other things) that throws CDRs.
    > > >
    > > > The billing system = collates all the CDRs.
    > > >
    > > > The spec required is, = of course, the format of the CDR and the way they
    > > > are transported.  = You could claim that a "transaction log" is a form of
    > > > CDR I suppose.
    > > >
    > > > I'd certainly agree = that SIP itself doesn't have any "billing package".
    > > > A UA and a server = might, but that is independent of the protocol.  Billing
    > > > might very well impact = some things in SIP.
    > > >
    > > > Brian
    > > >
    > > > > -----Original = Message-----
    > > > > From: Dean Willis = [mailto:dean.willis@wcom.com]
    > > > > Sent: Tuesday, = February 29, 2000 2:41 PM
    > > > > To: Mart Nurmet; = sip@lists.research.bell-labs.com
    > > > > Subject: RE: = Information request! (Billing Package?)
    > > > >
    > > > >
    > > > > What would a = billing package look like? I've never really understood the
    > > > > concept, and it = might be useful to talk about it some more.
    > > > >
    > > > > Here's how some = implementors are doing it:
    > > > >
    > > > > 1) Gateways throw = CDRs using RADIUS or something similar.
    > > > > This feeds into = rating, reporting, and billing systems,
    > > > >
    > > > > 2) SIP servers = record transaction logs. These may feed into rating and
    > > > > billing systems, = and probably feed into reporting systems.
    > > > >
    > > > > 3) QoS PEP and = PDPs log resource usages. These feed upstream as well.
    > > > >
    > > > > 4) Other systems, = like profile managers, report usage.
    > > > >
    > > > > 5) Rating, = reporting, and billing systems sift thru the vast amounts of
    > > > > information = coming at them and make useful things happen.
    > > > >
    > > > > All of these = things use other protocols and systems -- they aren't SIP
    > > > > specific. They do = rely on SIP functions like authentication
    > > > > -- that is, the = goal of achieving billing functions has driven some
    > > > > requirements into = the design of SIP. However, other than driving some
    > > requirements
    > > > > to SIP, such = efforts are generally considered to be outside the scope of
    > > > > the SIP = WG.
    > > > >
    > > > > Are you perhaps = proposing to add functionality to SIP to simplify or enhance
    > >
    > > > > reporting = capabilities or to simplify the task of driving downstream = billing
    > >
    > > > > systems?
    > > > >
    > > > > --
    > > > > Dena
    > > > > > = -----Original Message-----
    > > > > > From: = owner-sip@lists.research.bell-labs.com
    > > > > > = [mailto:owner-sip@= lists.research.bell-labs.com]On Behalf Of
    > > > > Mart = Nurmet
    > > > > > Sent: = Monday, February 28, 2000 2:24 PM
    > > > > > To: = sip@lists.research.bell-labs.com
    > > > > > Subject: = Information request! (Billing Package?)
    > > > > >
    > > > > >
    > > > > > I am looking = for information if there has been any work
    > > > > done to generate = a
    > > > > > billing = package for SIP.  From my look at the available
    > > > > > information = there does
    > > > > > not seem to = be any.  Is that the case or am I missing something?
    > > > > >
    > > > > > Thank = you,
    > > > > > -Mart
    > > > > >
    > > > > >
    > > > >
    > > > >

------_=_NextPart_001_01BF83C3.F9F64170-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 2 00:05:59 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24339 for ; Thu, 2 Mar 2000 00:05:59 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.81318A80@standards.nortelnetworks.com>; Thu, 2 Mar 2000 0:01:48 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 68644 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Mar 2000 00:01:38 -0500 Received: from rm-rstar.sfu.ca by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.15B52C40@standards.nortelnetworks.com>; Wed, 1 Mar 2000 23:51:38 -0500 Received: from cultus.sfu.ca (cultus.sfu.ca [142.58.101.5]) by rm-rstar.sfu.ca (8.9.2/8.9.2/SFU-5.0H) with ESMTP id UAA28324 for ; Wed, 1 Mar 2000 20:55:10 -0800 (PST) Content-Type: text/plain Content-Disposition: inline X-Sender: jpwong@popserver.sfu.ca Mime-Version: 1.0 X-Mailer: SFUwebmail 2.70 Message-ID: <200003020455.UAA28324@rm-rstar.sfu.ca> Date: Wed, 1 Mar 2000 20:55:09 PST Reply-To: Jerry Wong Sender: "Media Gateway Control (megaco)" From: Jerry Wong Subject: Auditing EventBuffer Descriptor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi Tom, list, Currently, the EventBuffer Descriptor is one of the legal descriptors for the AuditValue and AuditCapabilities commands (as listed in Section 7.2). However, the Spec has not explicitly stated what the two Audit commands should return for the EventBuffer Descriptor. It seems to me that the Audit for the ObservedEvents Descriptor is already returning what the EventBuffer Descriptor should return: (For AuditValue in Section 7.2.5: "ObservedEvents returns a list of events in the EventBuffer", and for AuditCapabilities in Section 7.2.6: "ObservedEventsDescriptor returns the names of active events on the termination"). Thx, Jerry From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 2 00:08:30 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24364 for ; Thu, 2 Mar 2000 00:08:30 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C9C0ACE0@standards.nortelnetworks.com>; Thu, 2 Mar 2000 0:03:50 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 68686 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Mar 2000 00:03:37 -0500 Received: from rm-rstar.sfu.ca by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C224BD00@standards.nortelnetworks.com>; Thu, 2 Mar 2000 0:03:37 -0500 Received: from cultus.sfu.ca (cultus.sfu.ca [142.58.101.5]) by rm-rstar.sfu.ca (8.9.2/8.9.2/SFU-5.0H) with ESMTP id VAA01982 for ; Wed, 1 Mar 2000 21:07:08 -0800 (PST) Content-Type: text/plain Content-Disposition: inline X-Sender: jpwong@popserver.sfu.ca Mime-Version: 1.0 X-Mailer: SFUwebmail 2.70 Message-ID: <200003020507.VAA01982@rm-rstar.sfu.ca> Date: Wed, 1 Mar 2000 21:07:08 PST Reply-To: Jerry Wong Sender: "Media Gateway Control (megaco)" From: Jerry Wong Subject: Example call flows To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi Tom, list, In the example call flows in Appendix A, Step 20, it seems to me that the TerminationState Descriptor (within the Media Descriptor) should also be returned from the AuditValue command (which is missing right now). Am I correct? Thx, Jerry From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 2 03:27:10 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08641 for ; Thu, 2 Mar 2000 03:27:09 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A0157EE0@standards.nortelnetworks.com>; Thu, 2 Mar 2000 3:23:06 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 68832 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Mar 2000 03:21:12 -0500 Received: from auemlsrv.firewall.lucent.com (192.11.223.161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5C786210@standards.nortelnetworks.com>; Thu, 2 Mar 2000 3:21:12 -0500 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 DAA22905 for ; Thu, 2 Mar 2000 03:24:44 -0500 (EST) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id DAA22892 for ; Thu, 2 Mar 2000 03:24:44 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA17406; Thu, 2 Mar 2000 09:24:43 +0100 (MET) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id JAA17390; Thu, 2 Mar 2000 09:24:28 +0100 (MET) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Original-CC: MEGACO@standards.nortelnetworks.com References: <200003020455.UAA28324@rm-rstar.sfu.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38BE253E.3405D3A4@lucent.com> Date: Thu, 2 Mar 2000 09:24:30 +0100 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: Auditing EventBuffer Descriptor X-To: Jerry Wong To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Jerry, The EventBufferDescriptor contains the events that the MG looks for when EventBufferControl equals LockStep. If an AuditValue command contains EventBuffer descriptor, the MG replies with this information, instead of the events in the EventBuffer. Cheers, John Jerry Wong wrote: > > Hi Tom, list, > > Currently, the EventBuffer Descriptor is one of the legal descriptors for the AuditValue and AuditCapabilities commands (as listed in Section 7.2). However, the Spec has not explicitly stated what the two Audit commands should return for the EventBuffer Descriptor. > > It seems to me that the Audit for the ObservedEvents Descriptor is already returning what the EventBuffer Descriptor should return: (For AuditValue in Section 7.2.5: "ObservedEvents returns a list of events in the EventBuffer", and for AuditCapabilities in Section 7.2.6: "ObservedEventsDescriptor returns the names of active events on the termination"). > > Thx, > Jerry -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 2 08:48:40 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12524 for ; Thu, 2 Mar 2000 08:48:39 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8AF4BD00@standards.nortelnetworks.com>; Thu, 2 Mar 2000 8:44:37 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 69204 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Mar 2000 08:43:20 -0500 Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F6DB0800@standards.nortelnetworks.com>; Thu, 2 Mar 2000 8:33:20 -0500 Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id PAA13016 for ; Thu, 2 Mar 2000 15:36:32 +0200 (EET) Received: from esebh03nok.ntc.nokia.com (esebh03nok.ntc.nokia.com [131.228.118.244]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id PAA28996 for ; Thu, 2 Mar 2000 15:34:04 +0200 (EET) Received: by esebh03nok with Internet Mail Service (5.5.2650.10) id ; Thu, 2 Mar 2000 15:34:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.10) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <771290CD2EE0D211B1940008C7894D0E01A2E404@eseis09nok> Date: Thu, 2 Mar 2000 15:33:45 +0200 Reply-To: marko.onikki@NOKIA.COM Sender: "Media Gateway Control (megaco)" From: Marko Onikki Subject: ServiChangeReply definition question? To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi, to everyone! Could someone tell to me is in MEGACO/H.248 v.15 specification error in ServiceChangeReply definition? ServiChangeReply is defined like this: ServiceChangeReply ::= SEQUENCE { terminationID TerminationIDList, serviceChangeResult ServiceChangeResult, -->> ServiceChangeResult OPTIONAL ... } -- For ServiceChangeResult, no parameters are mandatory. Hence the -- distinction between ServiceChangeParm and ServiceChangeResParm. My opinion is that ServiceChangeResult should be OPTIONAL part because ServiChangeResult is divided to CHOICE structure ServiceChangeResult ::= CHOICE { errorDescriptor ErrorDescriptor, serviceChangeResParms ServiceChangeResParm } ServiceChangeResParm ::= SEQUENCE { serviceChangeMgcId MId OPTIONAL, serviceChangeAddress ServiceChangeAddress OPTIONAL, serviceChangeVersion INTEGER(0..99) OPTIONAL, serviceChangeProfile ServiceChangeProfile OPTIONAL } and if ServiceChangeResParm is choosed there migth not be any data at all in ServiceChangeResParm because ServiceChangeResParm consist only from OPTIONAL parts. Br, Marko Onikki Nokia Networks E-mail. marko.onikki@nokia.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 2 10:09:03 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14408 for ; Thu, 2 Mar 2000 10:09:02 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C1B3C790@standards.nortelnetworks.com>; Thu, 2 Mar 2000 10:04:54 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 69399 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Mar 2000 10:04:52 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5B18A600@standards.nortelnetworks.com>; Thu, 2 Mar 2000 9:54:52 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id JAA09354 for ; Thu, 2 Mar 2000 09:58:23 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id JAA12484 for ; Thu, 2 Mar 2000 09:58:25 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id <1WCM1GXC>; Thu, 2 Mar 2000 09:54:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF208A50@whq-msgusr-02.fore.com> Date: Thu, 2 Mar 2000 09:58:05 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Auditing EventBuffer Descriptor To: MEGACO@STANDARDS.NORTELNETWORKS.COM I agree with John, AuditValue of EventBuffer returns the current value (which would be the same as what it was set to last). AuditCapabilities of EventBuffer would be identical to that of EventsDescriptor - a list of all events implemented on the MG. Brian > -----Original Message----- > From: John Segers [mailto:jsegers@lucent.com] > Sent: Thursday, March 02, 2000 3:25 AM > To: MEGACO@standards.nortelnetworks.com > Subject: Re: Auditing EventBuffer Descriptor > > > Jerry, > > The EventBufferDescriptor contains the events that the MG > looks for when > EventBufferControl equals LockStep. If an AuditValue command contains > EventBuffer descriptor, the MG replies with this information, > instead of > the events in the EventBuffer. > > Cheers, > > John > > Jerry Wong wrote: > > > > Hi Tom, list, > > > > Currently, the EventBuffer Descriptor is one of the legal > descriptors for the AuditValue and AuditCapabilities commands > (as listed in Section 7.2). However, the Spec has not > explicitly stated what the two Audit commands should return > for the EventBuffer Descriptor. > > > > It seems to me that the Audit for the ObservedEvents > Descriptor is already returning what the EventBuffer > Descriptor should return: (For AuditValue in Section 7.2.5: > "ObservedEvents returns a list of events in the EventBuffer", > and for AuditCapabilities in Section 7.2.6: > "ObservedEventsDescriptor returns the names of active events > on the termination"). > > > > Thx, > > Jerry > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 306 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 2 10:44:07 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15547 for ; Thu, 2 Mar 2000 10:44:06 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AA9D7E70@standards.nortelnetworks.com>; Thu, 2 Mar 2000 10:40:03 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 69533 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Mar 2000 10:38:57 -0500 Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1DDF2DE0@standards.nortelnetworks.com>; Thu, 2 Mar 2000 10:28:57 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15135; Thu, 2 Mar 2000 10:32:29 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200003021532.KAA15135@ietf.org> Date: Thu, 2 Mar 2000 10:32:28 -0500 Reply-To: Internet-Drafts@ietf.org Sender: "Media Gateway Control (megaco)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-megaco-ipphone-02.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 IP Phone Media Gateway Application Profile Author(s) : R. Bell, P. Blatherwick, P. Holland Filename : draft-ietf-megaco-ipphone-02.txt Pages : 13 Date : 01-Mar-00 This document specifies a particular application of the Megaco/H.248 Protocol [3] for control of Internet telephones: the Megaco IP Phone Media Gateway. The telephone itself is a Media Gateway (MG), controlled by the Megaco/H.248 Protocol, with application control intelligence located in the Media Gateway Controller (MGC). In order to achieve a high degree of interoperability and design efficiency in such end-user devices, a consistent architectural approach, a particular organization of terminations and packages, and a protocol profile are described. The approach makes use of existing protocol features and user interface related packages, and is thus a straight-forward application of the Megaco/H.248 Protocol. This document represents the current view from the TIA working group on VoIP telephone specification [1], TIA TR-41.3.4, with the intent of using this as part of its 'whole device' specification as an optional method of device control. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-megaco-ipphone-02.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-ipphone-02.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-ipphone-02.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: <20000301103714.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-megaco-ipphone-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-megaco-ipphone-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000301103714.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 2 12:01:32 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18442 for ; Thu, 2 Mar 2000 12:01:31 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.72FFD1B0@standards.nortelnetworks.com>; Thu, 2 Mar 2000 11:57:14 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 69667 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Mar 2000 11:56:35 -0500 Received: from mail-dns1-nj.dialogic.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5BADD160@standards.nortelnetworks.com>; Thu, 2 Mar 2000 11:56:35 -0500 Received: from mail4.dialogic.com (mail4.dialogic.com [146.152.6.40]) by mail-dns1-nj.dialogic.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.11 1999/11/10 17:27:15 spurcell Exp $) with ESMTP id RAA15080 for ; Thu, 2 Mar 2000 17:01:35 GMT Received: from exchange3nj.dialogic.com (mailnj.dialogic.com [146.152.3.18]) by mail4.dialogic.com (PMDF V5.2-31 #40816) with ESMTP id <0FQT009PM0K2R8@mail4.dialogic.com> for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Mar 2000 12:00:02 -0500 (EST) Received: from STIEGLITZ ([146.152.84.25]) by exchange3nj.dialogic.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GDMR4A9X; Thu, 02 Mar 2000 12:00:03 -0500 X-Sender: magnells@exchange1nj.dialogic.com MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Message-ID: <3.0.3.32.20000302115939.0575424c@exchange1nj.dialogic.com> Date: Thu, 2 Mar 2000 11:59:39 -0500 Reply-To: Steven Magnell Sender: "Media Gateway Control (megaco)" From: Steven Magnell Subject: A small event handling ambiguity To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7BIT Maybe I was just too tired at the time we last discussed event handling, but there seems to be a small ambiguity in the current description of event handling (section 7.1.9) If the current state of event handling is where the MG is in LockStep mode, processing events from the event buffer, event buffer control can be set to off independent from loading of a new events descriptor. If this happens, all events in the buffer are discarded. The description of handling events when in LockStep mode are all with respect to processing events when a new descriptor has been loaded. For example, Case 2: "If EventBufferControl equals Off and the MG receives a new EventsDescriptor, it processes new events with the new EventsDescriptor". The ambiguity, at least in my mind, is what happens if no new events descriptor has been loaded since the last event was detected and notified. Does the MG, once event buffer control has been set to off, process events according to the last loaded events descriptor, even if it was deactivated since it had detected an event while in LockStep mode, or is there now no active events descriptor and a new one must be loaded before any event processing can happen? Comments, Answers? Thanks, steve magnell From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 2 16:18:56 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27536 for ; Thu, 2 Mar 2000 16:18:56 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.691860D0@standards.nortelnetworks.com>; Thu, 2 Mar 2000 16:14:39 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 70014 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 2 Mar 2000 16:13:10 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.343233F0@standards.nortelnetworks.com>; Thu, 2 Mar 2000 16:13:10 -0500 Received: from zmers013 by smtprch1.nortel.com; Thu, 2 Mar 2000 14:25:12 -0600 Received: from zrchb213.us.nortel.com (actually zrchb213) by zmers013; Thu, 2 Mar 2000 15:24:41 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Mar 2000 14:24:40 -0600 X-Mailer: Internet Mail Service (5.5.2650.21) Message-ID: Date: Thu, 2 Mar 2000 14:24:35 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: New Megaco Meeting Time To: MEGACO@STANDARDS.NORTELNETWORKS.COM The latest draft of the agenda for the Adelaide meeting shows Megaco meeting Thursday rather than Tuesday morning. Here is the lineup: THURSDAY, March 30, 2000 0800-1700 IETF Registration - Foyer 1 0800-0900 Continental Breakfast - Foyer and Circulation Area 0900-1130 Morning Sessions APP msgtrk Message Tracking WG OPS snmpconf Configuration Management with SNMP WG SEC ipsec IP Security Protocol WG TSV malloc Multicast-Address Allocation WG * TSV megaco Media Gateway Control WG USV weird Web Elucidation of Internet-Related Developments WG Tom Taylor Advisor -- Emerging Carrier IP Standards E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 3 05:10:04 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21948 for ; Fri, 3 Mar 2000 05:10:04 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2218C000@standards.nortelnetworks.com>; Fri, 3 Mar 2000 5:05:46 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 70851 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Mar 2000 05:04:29 -0500 Received: from relay.mail.pipex.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F4310A80@standards.nortelnetworks.com>; Fri, 3 Mar 2000 5:04:28 -0500 Received: (qmail 6365 invoked from network); 3 Mar 2000 09:46:10 -0000 Received: from gatekeeper.sgcs.co.uk (HELO bevx03.gpt.co.uk) (194.129.217.113) by iprelay.mail.pipex.net with SMTP; 3 Mar 2000 09:46:10 -0000 Received: from CONVERSION-DAEMON by siemenscomms.co.uk (PMDF V5.1-12 #D3115) id <01JMLB7S4FHC90N9RW@siemenscomms.co.uk> for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Mar 2000 09:42:02 GMT Received: from beex01.sgcs.co.uk ([19.0.53.101]) by siemenscomms.co.uk (PMDF V5.1-12 #D3115) with ESMTP id <01JMLB78O3AO90N3OG@siemenscomms.co.uk> for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 03 Mar 2000 09:39:45 +0000 (GMT) Received: by beex01.sgcs.co.uk with Internet Mail Service (5.5.2448.0) id ; Fri, 03 Mar 2000 09:43:31 +0000 Content-return: allowed MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Message-ID: <5AC7D3F55147D311AA1700A0C99583ED2C3687@beex03.sgcs.co.uk> Date: Fri, 3 Mar 2000 09:43:29 +0000 Reply-To: "Drage, Keith" Sender: "Media Gateway Control (megaco)" Comments: *********************************************** Comments: * Our domain is now siemenscomms.co.uk * Comments: * Please update your address book accordingly * Comments: *********************************************** From: "Drage, Keith" Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7BIT I note that this proposed profile contains the text: "Megaco IP Phone MGs MUST support text encoding of the protocol, as specified in the Megaco/H.248 Protocol document [3]." While I DO NOT want to reopen the encoding debate, it seems inappropriate to me that MEGACO should create a profile that further restricts it own product. I understood the summary of the text versus binary debate was that the decision on encoding would be made by market forces, and was NOT application dependent. If there is an application dependency, then guidelines to that dependency should surely be given in the main MEGACO protocol document. Surely it also dishonours the agreement between the ITU-T and IETF groups, as they participated in agreeing the words that go in H.248/MEGACO, but do not apparently participate in discussing the profile that then gets subsequently published by IETF. I would have therefore thought that if TIA wish to restrict the encoding choice, then it is up to TIA to publish the profile, rather than the IETF. Looking further, I notice that the document also defines constraints on the usage of Events, etc. Reading the main MEGACO protocol document, I understand that variations on termination characteristics should be implemented by specification of a package. Should these restrictions therefore be defined by a new package? I guess we need some general discussion on what is possible in profiles, as opposed to packages, and whether MEGACO should define profiles that are still nominally called MEGACO, but do not exhibit all the requirements of the main document. Rephrasing in a slightly different way, which are the options, and which of these options that are selected based on the type of application (and therefore suitable for specification in profiles for a particular application), and which are implementation options (and selected because an implementor wishes to make his product different and presumably better/cheaper/fit the available memory than another market entrant). Rephrasing the question a different way, with the restrictions imposed by this "profile", can the result still be MEGACO/H.248, or has it really invented a new protocol? Let me stress again, I do not want to see any responses that it is done this way because text is better than binary, or more efficient. The answer to that is irrelevant to the point I am trying to make. Keith Drage > --------------------------------------------------------------- > Keith Drage (keith.drage@siemenscomms.co.uk) > Siemens Communications Limited, > Technology Drive, Beeston, Nottingham NG9 1LA, UK > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > --------------------------------------------------------------- > Internet communications are not secure and therefore Siemens > Communications Limited does not accept legal responsibility for the > contents of this message. Any views or opinions presented are solely > those of the author and do not necessarily represent those of Siemens > Communications Limited unless otherwise specifically stated. > > 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 IP Phone Media Gateway > Application Profile > Author(s) : R. Bell, P. Blatherwick, P. Holland > Filename : draft-ietf-megaco-ipphone-02.txt > Pages : 13 > Date : 01-Mar-00 > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-megaco-ipphone-02.txt > > --------------------------------------------------------------- > Keith Drage (keith.drage@siemenscomms.co.uk) > Siemens Communications Limited, > Technology Drive, Beeston, Nottingham NG9 1LA, UK > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > --------------------------------------------------------------- > Internet communications are not secure and therefore Siemens > Communications Limited does not accept legal responsibility for the > contents of this message. Any views or opinions presented are solely those > of the author and do not necessarily represent those of Siemens > Communications Limited unless otherwise specifically stated. > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 3 07:31:17 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24173 for ; Fri, 3 Mar 2000 07:31:17 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E347E130@standards.nortelnetworks.com>; Fri, 3 Mar 2000 7:27:10 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 71094 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Mar 2000 07:25:25 -0500 Received: from gw-nl4.philips.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3F0312D0@standards.nortelnetworks.com>; Fri, 3 Mar 2000 7:15:25 -0500 Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl4.philips.com with ESMTP id NAA15350 for ; Fri, 3 Mar 2000 13:18:39 +0100 (MET) (envelope-from frank.derks@philips.com) Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl4.philips.com via mwrap (4.0a) id xma015348; Fri, 3 Mar 00 13:18:39 +0100 Received: from notessmtp-nl1.philips.com (notessmtp-nl1.philips.com [130.139.36.10]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id NAA27296 for ; Fri, 3 Mar 2000 13:18:39 +0100 (MET) Received: from EHLMS01.DIAMOND.PHILIPS.COM (ehlms01sv1.diamond.philips.com [130.139.54.212]) by notessmtp-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id NAA27787 for ; Fri, 3 Mar 2000 13:18:38 +0100 (MET) Received: by EHLMS01.DIAMOND.PHILIPS.COM (Soft-Switch LMS 4.0) with snapi via EMEA2 id 0056890009311852; Fri, 3 Mar 2000 13:18:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; name="MEMO 03/03/00 13:15:21" Content-Disposition: inline Message-ID: <0056890009311852000002L922*@MHS> Date: Fri, 3 Mar 2000 13:18:34 +0100 Reply-To: frank.derks@PHILIPS.COM Sender: "Media Gateway Control (megaco)" From: frank.derks@PHILIPS.COM Subject: MEGACO IP-Phone - H.248 Annex G To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA24173 Can anyone tell me where I can find the H.248 Annex G or the equivalent draft RFC? Frank From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 3 07:47:15 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24579 for ; Fri, 3 Mar 2000 07:47:15 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.21222900@standards.nortelnetworks.com>; Fri, 3 Mar 2000 7:43:13 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 71135 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Mar 2000 07:42:12 -0500 Received: from fire.integralaccess.com (63.160.25.239) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.970B78D0@standards.nortelnetworks.com>; Fri, 3 Mar 2000 7:32:12 -0500 Received: from akankkunen [192.168.1.23] by fire.integralaccess.com (SMTPD32-6.00) id A1F1E450106; Fri, 03 Mar 2000 07:37:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: Date: Fri, 3 Mar 2000 07:37:56 -0500 Reply-To: Antti Kankkunen Sender: "Media Gateway Control (megaco)" From: Antti Kankkunen Subject: VoMPLS Framework ID To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit FYI >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-kankkunen-vompls-fw-00.txt >Date: Thu, 02 Mar 2000 10:32:20 -0500 >Sender: nsyracus@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : Voice over MPLS Framework > Author(s) : A. Kankkunen, G. Ash, J. Hopkins, > B. Rosen, D. Stacey, A. Yelundur, L. Berger > Filename : draft-kankkunen-vompls-fw-00.txt > Pages : 51 > Date : 01-Mar-00 > >This document provides a Framework for using MPLS as the >underlying technology for transporting IP based public voice >services. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-kankkunen-vompls-fw-00.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-kankkunen-vompls-fw-00.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-kankkunen-vompls-fw-00.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. >Content-Type: text/plain >Content-ID: <20000301084456.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-kankkunen-vompls-fw-00.txt > > Best regards, Antti K. ------------------- Antti Kankkunen Integral Access Inc. 6 Omni Way Chelmsford, MA 01824 Phone: +1 978 256 8833 x 232 Mobile: +1 617 513 2172 Fax: +1 978 256 8077 e-mail: anttik@integralaccess.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 3 08:17:18 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25588 for ; Fri, 3 Mar 2000 08:17:17 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.535E20A0@standards.nortelnetworks.com>; Fri, 3 Mar 2000 8:13:15 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 71168 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Mar 2000 08:11:56 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BE74E6A0@standards.nortelnetworks.com>; Fri, 3 Mar 2000 8:01:56 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id IAA01096; Fri, 3 Mar 2000 08:05:27 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id IAA03589; Fri, 3 Mar 2000 08:05:24 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id <1WCM1VNK>; Fri, 3 Mar 2000 08:01:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF208A5E@whq-msgusr-02.fore.com> Date: Fri, 3 Mar 2000 08:05:04 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt X-To: "Drage, Keith" To: MEGACO@STANDARDS.NORTELNETWORKS.COM There are two threads in this message I wish to comment on. 1. The issue of text encoding. Text/Binary Encoding is defined in the protocol as optional. A profile could make a choice. It is acceptable to me that such a choice be made in this profile. 2. Subsets of the protocol. I have been vociferous in positing that profiles cannot subset the protocol. If the protocol defines something as optional, then the profile can declare what options shall be implemented. Where there is not an option, profiles should not make something optional. If it does, it's a new protocol. Call it that, and we can decide if we want to standardize a new protocol. I personally do not believe that an IPPhone needs to subset the Megaco protocol. Brian > -----Original Message----- > From: Drage, Keith [mailto:Keith.Drage@SIEMENSCOMMS.CO.UK] > Sent: Friday, March 03, 2000 4:43 AM > To: MEGACO@standards.nortelnetworks.com > Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt > > > I note that this proposed profile contains the text: > > "Megaco IP Phone MGs MUST support text encoding of the protocol, as > specified in the Megaco/H.248 Protocol document [3]." > > While I DO NOT want to reopen the encoding debate, it seems > inappropriate to > me that MEGACO should create a profile that further restricts it own > product. I understood the summary of the text versus binary > debate was that > the decision on encoding would be made by market forces, and was NOT > application dependent. If there is an application dependency, then > guidelines to that dependency should surely be given in the > main MEGACO > protocol document. > > Surely it also dishonours the agreement between the ITU-T and > IETF groups, > as they participated in agreeing the words that go in > H.248/MEGACO, but do > not apparently participate in discussing the profile that then gets > subsequently published by IETF. > > I would have therefore thought that if TIA wish to restrict > the encoding > choice, then it is up to TIA to publish the profile, rather > than the IETF. > > Looking further, I notice that the document also defines > constraints on the > usage of Events, etc. Reading the main MEGACO protocol document, I > understand that variations on termination characteristics should be > implemented by specification of a package. Should these restrictions > therefore be defined by a new package? > > I guess we need some general discussion on what is possible > in profiles, as > opposed to packages, and whether MEGACO should define > profiles that are > still nominally called MEGACO, but do not exhibit all the > requirements of > the main document. Rephrasing in a slightly different way, > which are the > options, and which of these options that are selected based > on the type of > application (and therefore suitable for specification in > profiles for a > particular application), and which are implementation options > (and selected > because an implementor wishes to make his product different > and presumably > better/cheaper/fit the available memory than another market entrant). > > Rephrasing the question a different way, with the > restrictions imposed by > this "profile", can the result still be MEGACO/H.248, or has it really > invented a new protocol? > > Let me stress again, I do not want to see any responses that > it is done this > way because text is better than binary, or more efficient. > The answer to > that is irrelevant to the point I am trying to make. > > Keith Drage > > > > --------------------------------------------------------------- > > Keith Drage (keith.drage@siemenscomms.co.uk) > > Siemens Communications Limited, > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > --------------------------------------------------------------- > > Internet communications are not secure and therefore Siemens > > Communications Limited does not accept legal responsibility for the > > contents of this message. Any views or opinions presented are solely > > those of the author and do not necessarily represent those > of Siemens > > Communications Limited unless otherwise specifically stated. > > > > 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 IP Phone Media Gateway > > Application Profile > > Author(s) : R. Bell, P. Blatherwick, P. Holland > > Filename : draft-ietf-megaco-ipphone-02.txt > > Pages : 13 > > Date : 01-Mar-00 > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-megaco-ipphone-02.txt > > > > > > --------------------------------------------------------------- > > Keith Drage (keith.drage@siemenscomms.co.uk) > > Siemens Communications Limited, > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > --------------------------------------------------------------- > > Internet communications are not secure and therefore Siemens > > Communications Limited does not accept legal responsibility for the > > contents of this message. Any views or opinions presented > are solely those > > of the author and do not necessarily represent those of Siemens > > Communications Limited unless otherwise specifically stated. > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 3 08:40:40 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26394 for ; Fri, 3 Mar 2000 08:40:28 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8B1826A0@standards.nortelnetworks.com>; Fri, 3 Mar 2000 8:36:17 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 71192 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Mar 2000 08:35:09 -0500 Received: from ltau.lt.br.np.els-gms.att.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.61F09140@standards.nortelnetworks.com>; Fri, 3 Mar 2000 8:35:08 -0500 Received: from mikebuckley by attmail; Fri Mar 3 13:37:27 GMT 2000 Encoding-Type: ISO8859.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: Date: Fri, 3 Mar 2000 13:35:16 +0000 Reply-To: Mike Buckley Sender: "Media Gateway Control (megaco)" From: Mike Buckley Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt X-To: "Rosen, Brian" , ITU-SG16@MAILBAG.INTEL.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I agree wholeheartedly with Keith Drage's comment: >Surely it also dishonours the agreement between the ITU-T and IETF groups, >as they participated in agreeing the words that go in H.248/MEGACO, but do >not apparently participate in discussing the profile that then gets >subsequently published by IETF. This attempt to sidestep the agreement with the ITU can only create bad faith between the two organizations. The Megaco wording was arrived at after lengthy discussions and compromise on both sides. The consequences of unilaterally trying to pursue one line will ony result in the ITU going off in an incompatible direction. Is this what the market wants - an IETF package specifying text encoding and an ITU Annex specifying binary? This is not the way to resolve the text v. binary issue and it is not the way to built good relations between the two Standards bodies. Agreements should be honoured by both sides in the spirit as well as the letter. Mike Buckley ____________________ Begin Original Message ___________________________ Date: Fri Mar 3 08:05:04 -0500 2000 From: internet!FORE.COM!brosen (Rosen, Brian) Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt To: internet!STANDARDS.NORTELNETWORKS.COM!MEGACO Content-Type: Generic-Text Content-Length: 5599 There are two threads in this message I wish to comment on. 1. The issue of text encoding. Text/Binary Encoding is defined in the protocol as optional. A profile could make a choice. It is acceptable to me that such a choice be made in this profile. 2. Subsets of the protocol. I have been vociferous in positing that profiles cannot subset the protocol. If the protocol defines something as optional, then the profile can declare what options shall be implemented. Where there is not an option, profiles should not make something optional. If it does, it's a new protocol. Call it that, and we can decide if we want to standardize a new protocol. I personally do not believe that an IPPhone needs to subset the Megaco protocol. Brian > -----Original Message----- > From: Drage, Keith [mailto:Keith.Drage@SIEMENSCOMMS.CO.UK] > Sent: Friday, March 03, 2000 4:43 AM > To: MEGACO@standards.nortelnetworks.com > Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt > > > I note that this proposed profile contains the text: > > "Megaco IP Phone MGs MUST support text encoding of the protocol, as > specified in the Megaco/H.248 Protocol document [3]." > > While I DO NOT want to reopen the encoding debate, it seems > inappropriate to > me that MEGACO should create a profile that further restricts it own > product. I understood the summary of the text versus binary > debate was that > the decision on encoding would be made by market forces, and was NOT > application dependent. If there is an application dependency, then > guidelines to that dependency should surely be given in the > main MEGACO > protocol document. > > Surely it also dishonours the agreement between the ITU-T and > IETF groups, > as they participated in agreeing the words that go in > H.248/MEGACO, but do > not apparently participate in discussing the profile that then gets > subsequently published by IETF. > > I would have therefore thought that if TIA wish to restrict > the encoding > choice, then it is up to TIA to publish the profile, rather > than the IETF. > > Looking further, I notice that the document also defines > constraints on the > usage of Events, etc. Reading the main MEGACO protocol document, I > understand that variations on termination characteristics should be > implemented by specification of a package. Should these restrictions > therefore be defined by a new package? > > I guess we need some general discussion on what is possible > in profiles, as > opposed to packages, and whether MEGACO should define > profiles that are > still nominally called MEGACO, but do not exhibit all the > requirements of > the main document. Rephrasing in a slightly different way, > which are the > options, and which of these options that are selected based > on the type of > application (and therefore suitable for specification in > profiles for a > particular application), and which are implementation options > (and selected > because an implementor wishes to make his product different > and presumably > better/cheaper/fit the available memory than another market entrant). > > Rephrasing the question a different way, with the > restrictions imposed by > this "profile", can the result still be MEGACO/H.248, or has it really > invented a new protocol? > > Let me stress again, I do not want to see any responses that > it is done this > way because text is better than binary, or more efficient. > The answer to > that is irrelevant to the point I am trying to make. > > Keith Drage > > > > --------------------------------------------------------------- > > Keith Drage (keith.drage@siemenscomms.co.uk) > > Siemens Communications Limited, > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > --------------------------------------------------------------- > > Internet communications are not secure and therefore Siemens > > Communications Limited does not accept legal responsibility for the > > contents of this message. Any views or opinions presented are solely > > those of the author and do not necessarily represent those > of Siemens > > Communications Limited unless otherwise specifically stated. > > > > 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 IP Phone Media Gateway > > Application Profile > > Author(s) : R. Bell, P. Blatherwick, P. Holland > > Filename : draft-ietf-megaco-ipphone-02.txt > > Pages : 13 > > Date : 01-Mar-00 > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-megaco-ipphone-02.txt > > > > > > --------------------------------------------------------------- > > Keith Drage (keith.drage@siemenscomms.co.uk) > > Siemens Communications Limited, > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > --------------------------------------------------------------- > > Internet communications are not secure and therefore Siemens > > Communications Limited does not accept legal responsibility for the > > contents of this message. Any views or opinions presented > are solely those > > of the author and do not necessarily represent those of Siemens > > Communications Limited unless otherwise specifically stated. > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 3 09:22:38 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27935 for ; Fri, 3 Mar 2000 09:22:35 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6CCAAD70@standards.nortelnetworks.com>; Fri, 3 Mar 2000 9:18:23 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 71272 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Mar 2000 09:17:23 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.48869EB0@standards.nortelnetworks.com>; Fri, 3 Mar 2000 9:17:22 -0500 Received: from zmers013 by smtprch1.nortel.com; Fri, 3 Mar 2000 08:20:54 -0600 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by zmers013; Fri, 3 Mar 2000 09:20:27 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Mar 2000 09:18:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF851B.5AEDB122" Message-ID: Date: Fri, 3 Mar 2000 09:18:32 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt 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_01BF851B.5AEDB122 Content-Type: text/plain; charset="iso-8859-1" One of the key issues is what the Working Group wishes to do with the IP Phone document. I'd say the choices are these, but I'm being a little arbitrary here: (1) The document is Standards Track and is an official Megaco output. In that case, I think it should conform entirely to the spirit of the main protocol document (i.e. I'll concede Mike and Keith's points). I will point out that the main protocol document does NOT require an MG to support a specific encoding. (2) The document is Informational and is an official Megaco output. In that case, I think it should conform to the position as stated by Brian. We have the right to select from options, but not to modify the actual protocol we have produced. (3) The document is not an official Megaco output. In that case, the TIA has the right to publish what they want, subject to IESG approval. Of course, the IESG may refer it to us for comment. > -----Original Message----- > From: Mike Buckley [SMTP:mikebuckley@ATTMAIL.COM] > Sent: Friday, March 03, 2000 8:35 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt > > I agree wholeheartedly with Keith Drage's comment: > > >Surely it also dishonours the agreement between the ITU-T and IETF > groups, > >as they participated in agreeing the words that go in H.248/MEGACO, but > do > >not apparently participate in discussing the profile that then gets > >subsequently published by IETF. > > This attempt to sidestep the agreement with the ITU can only create bad > faith > between the two organizations. The Megaco wording was arrived at after > lengthy > discussions and compromise on both sides. The consequences of > unilaterally > trying to pursue one line will ony result in the ITU going off in an > incompatible > direction. Is this what the market wants - an IETF package specifying > text > encoding and an ITU Annex specifying binary? > > This is not the way to resolve the text v. binary issue and it is not the > way to built > good relations between the two Standards bodies. > > Agreements should be honoured by both sides in the spirit as well as the > letter. > > Mike Buckley > > > ____________________ Begin Original Message > ___________________________ > Date: Fri Mar 3 08:05:04 -0500 2000 > From: internet!FORE.COM!brosen (Rosen, Brian) > Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt > To: internet!STANDARDS.NORTELNETWORKS.COM!MEGACO > Content-Type: Generic-Text > Content-Length: 5599 > > There are two threads in this message I wish to comment on. > 1. The issue of text encoding. Text/Binary Encoding is defined > in the protocol as optional. A profile could make a choice. > It is acceptable to me that such a choice be made in this profile. > > 2. Subsets of the protocol. I have been vociferous in positing > that profiles cannot subset the protocol. If the protocol > defines something as optional, then the profile can declare > what options shall be implemented. Where there is not an option, > profiles should not make something optional. If it does, it's > a new protocol. Call it that, and we can decide if we want > to standardize a new protocol. I personally do not believe that > an IPPhone needs to subset the Megaco protocol. > > Brian > > > > > -----Original Message----- > > From: Drage, Keith [mailto:Keith.Drage@SIEMENSCOMMS.CO.UK] > > Sent: Friday, March 03, 2000 4:43 AM > > To: MEGACO@standards.nortelnetworks.com > > Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt > > > > > > I note that this proposed profile contains the text: > > > > "Megaco IP Phone MGs MUST support text encoding of the protocol, as > > specified in the Megaco/H.248 Protocol document [3]." > > > > While I DO NOT want to reopen the encoding debate, it seems > > inappropriate to > > me that MEGACO should create a profile that further restricts it own > > product. I understood the summary of the text versus binary > > debate was that > > the decision on encoding would be made by market forces, and was NOT > > application dependent. If there is an application dependency, then > > guidelines to that dependency should surely be given in the > > main MEGACO > > protocol document. > > > > Surely it also dishonours the agreement between the ITU-T and > > IETF groups, > > as they participated in agreeing the words that go in > > H.248/MEGACO, but do > > not apparently participate in discussing the profile that then gets > > subsequently published by IETF. > > > > I would have therefore thought that if TIA wish to restrict > > the encoding > > choice, then it is up to TIA to publish the profile, rather > > than the IETF. > > > > Looking further, I notice that the document also defines > > constraints on the > > usage of Events, etc. Reading the main MEGACO protocol document, I > > understand that variations on termination characteristics should be > > implemented by specification of a package. Should these restrictions > > therefore be defined by a new package? > > > > I guess we need some general discussion on what is possible > > in profiles, as > > opposed to packages, and whether MEGACO should define > > profiles that are > > still nominally called MEGACO, but do not exhibit all the > > requirements of > > the main document. Rephrasing in a slightly different way, > > which are the > > options, and which of these options that are selected based > > on the type of > > application (and therefore suitable for specification in > > profiles for a > > particular application), and which are implementation options > > (and selected > > because an implementor wishes to make his product different > > and presumably > > better/cheaper/fit the available memory than another market entrant). > > > > Rephrasing the question a different way, with the > > restrictions imposed by > > this "profile", can the result still be MEGACO/H.248, or has it really > > invented a new protocol? > > > > Let me stress again, I do not want to see any responses that > > it is done this > > way because text is better than binary, or more efficient. > > The answer to > > that is irrelevant to the point I am trying to make. > > > > Keith Drage > > > > > > > --------------------------------------------------------------- > > > Keith Drage (keith.drage@siemenscomms.co.uk) > > > Siemens Communications Limited, > > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > > --------------------------------------------------------------- > > > Internet communications are not secure and therefore Siemens > > > Communications Limited does not accept legal responsibility for the > > > contents of this message. Any views or opinions presented are solely > > > those of the author and do not necessarily represent those > > of Siemens > > > Communications Limited unless otherwise specifically stated. > > > > > > 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 IP Phone Media Gateway > > > Application Profile > > > Author(s) : R. Bell, P. Blatherwick, P. Holland > > > Filename : draft-ietf-megaco-ipphone-02.txt > > > Pages : 13 > > > Date : 01-Mar-00 > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-megaco-ipphone-02.txt > > > > > > > > > > --------------------------------------------------------------- > > > Keith Drage (keith.drage@siemenscomms.co.uk) > > > Siemens Communications Limited, > > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > > --------------------------------------------------------------- > > > Internet communications are not secure and therefore Siemens > > > Communications Limited does not accept legal responsibility for the > > > contents of this message. Any views or opinions presented > > are solely those > > > of the author and do not necessarily represent those of Siemens > > > Communications Limited unless otherwise specifically stated. > > > > > > > > ------_=_NextPart_001_01BF851B.5AEDB122 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-megaco-ipphone-02.txt

One of the key = issues is what the Working Group wishes to do with the IP Phone = document.  I'd say the choices are these, but I'm being a little = arbitrary here:

  (1) The = document is Standards Track and is an official Megaco output.  In = that case, I think it should conform entirely to the spirit of the main = protocol document (i.e. I'll concede Mike and Keith's points).  I = will point out that the main protocol document does NOT require an MG = to support a specific encoding.

  (2) The = document is Informational and is an official Megaco output.  In = that case, I think it should conform to the position as stated by = Brian.  We have the right to select from options, but not to = modify the actual protocol we have produced.

  (3) The = document is not an official Megaco output.  In that case, the TIA = has the right to publish what they want, subject to IESG  = approval.  Of course, the IESG may refer it to us for = comment.

    -----Original Message-----
    From:   Mike Buckley = [SMTP:mikebuckley@ATTMAIL.COM]
    Sent:   Friday, March 03, 2000 8:35 AM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: I-D = ACTION:draft-ietf-megaco-ipphone-02.txt

    I agree wholeheartedly with Keith = Drage's comment:

    >Surely it also dishonours the = agreement between the ITU-T and IETF groups,
    >as they participated in agreeing = the words that go in H.248/MEGACO, but do
    >not apparently participate in = discussing the profile that then gets
    >subsequently published by = IETF.

    This attempt to sidestep the agreement = with the ITU can only create bad faith
    between the two organizations.  = The Megaco wording was arrived at after lengthy
    discussions and compromise on both = sides.  The consequences of unilaterally
    trying to pursue one line will ony = result in the ITU going off in an incompatible
    direction.  Is this what the = market wants - an IETF package specifying text
    encoding and an ITU Annex specifying = binary?

    This is not the way to resolve the = text v. binary issue and it is not the way to built
    good relations between the two = Standards bodies.

    Agreements should be honoured by both = sides in the spirit as well as the letter.

    Mike Buckley


    ____________________ Begin Original = Message
    ___________________________
    Date: Fri Mar  3 08:05:04 -0500 = 2000
    From: internet!FORE.COM!brosen = (Rosen, Brian)
    Subject: Re: I-D = ACTION:draft-ietf-megaco-ipphone-02.txt
    To: = internet!STANDARDS.NORTELNETWORKS.COM!MEGACO
    Content-Type: Generic-Text
    Content-Length: 5599

    There are two threads in this message = I wish to comment on.
    1. The issue of text encoding.  = Text/Binary Encoding is defined
    in the protocol as optional. A = profile could make a choice.
    It is acceptable to me that such a = choice be made in this profile.

    2. Subsets of the protocol.  I = have been vociferous in positing
    that profiles cannot subset the = protocol.  If the protocol
    defines something as optional, then = the profile can declare
    what options shall be = implemented.  Where there is not an option,
    profiles should not make something = optional.  If it does, it's
    a new protocol.  Call it that, = and we can decide if we want
    to standardize a new protocol.  = I personally do not believe that
    an IPPhone needs to subset the Megaco = protocol.

    Brian



    > -----Original Message-----
    > From: Drage, Keith = [mailto:Keith.Drage@SIEMEN= SCOMMS.CO.UK]
    > Sent: Friday, March 03, 2000 = 4:43 AM
    > To: = MEGACO@standards.nortelnetworks.com
    > Subject: Re: I-D = ACTION:draft-ietf-megaco-ipphone-02.txt
    >
    >
    > I note that this proposed = profile contains the text:
    >
    > "Megaco IP Phone MGs MUST = support text encoding of the protocol, as
    > specified in the Megaco/H.248 = Protocol document [3]."
    >
    > While I DO NOT want to reopen = the encoding debate, it seems
    > inappropriate to
    > me that MEGACO should create a = profile that further restricts it own
    > product. I understood the = summary of the text versus binary
    > debate was that
    > the decision on encoding would = be made by market forces, and was NOT
    > application dependent. If there = is an application dependency, then
    > guidelines to that dependency = should surely be given in the
    > main MEGACO
    > protocol document.
    >
    > Surely it also dishonours the = agreement between the ITU-T and
    > IETF groups,
    > as they participated in agreeing = the words that go in
    > H.248/MEGACO, but do
    > not apparently participate in = discussing the profile that then gets
    > subsequently published by = IETF.
    >
    > I would have therefore thought = that if TIA wish to restrict
    > the encoding
    > choice, then it is up to TIA to = publish the profile, rather
    > than the IETF.
    >
    > Looking further, I notice that = the document also defines
    > constraints on the
    > usage of Events, etc. Reading = the main MEGACO protocol document, I
    > understand that variations on = termination characteristics should be
    > implemented by specification of = a package. Should these restrictions
    > therefore be defined by a new = package?
    >
    > I guess we need some general = discussion on what is possible
    > in profiles, as
    > opposed to packages, and whether = MEGACO should define
    > profiles that are
    > still nominally called MEGACO, = but do not exhibit all the
    > requirements of
    > the main document. Rephrasing in = a slightly different way,
    > which are the
    > options, and which of these = options that are selected based
    > on the type of
    > application (and therefore = suitable for specification in
    > profiles for a
    > particular application), and = which are implementation options
    > (and selected
    > because an implementor wishes to = make his product different
    > and presumably
    > better/cheaper/fit the available = memory than another market entrant).
    >
    > Rephrasing the question a = different way, with the
    > restrictions imposed by
    > this "profile", can = the result still be MEGACO/H.248, or has it really
    > invented a new protocol?
    >
    > Let me stress again, I do not = want to see any responses that
    > it is done this
    > way because text is better than = binary, or more efficient.
    > The answer to
    > that is irrelevant to the point = I am trying to make.
    >
    > Keith Drage
    >
    >
    > > = ---------------------------------------------------------------
    > > Keith Drage = (keith.drage@siemenscomms.co.uk)
    > > Siemens Communications = Limited,
    > > Technology Drive, Beeston, = Nottingham NG9 1LA, UK
    > > Tel: +44 115 943 = 4991   Fax: +44 115 943 4992
    > > = ---------------------------------------------------------------
    > > Internet communications are = not secure and therefore Siemens
    > > Communications Limited does = not accept legal responsibility for the
    > > contents of this message. = Any views or opinions presented are solely
    > > those of the author and do = not necessarily represent those
    > of Siemens
    > > Communications Limited = unless otherwise specifically stated.
    > >
    > > 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 IP Phone Media Gateway
    > > Application Profile
    > = >         = Author(s)       : R. Bell,  P. = Blatherwick, P. Holland
    > = >         = Filename        : = draft-ietf-megaco-ipphone-02.txt
    > = >         = Pages           : = 13
    > = >         = Date            = : 01-Mar-00
    > >
    > > A URL for this = Internet-Draft is:
    > > http://www.ietf.org/internet-drafts/draft-ietf-megaco-= ipphone-02.txt
    > >
    >
    >
    > > = ---------------------------------------------------------------
    > > Keith Drage = (keith.drage@siemenscomms.co.uk)
    > > Siemens Communications = Limited,
    > > Technology Drive, Beeston, = Nottingham NG9 1LA, UK
    > > Tel: +44 115 943 = 4991   Fax: +44 115 943 4992
    > > = ---------------------------------------------------------------
    > > Internet communications are = not secure and therefore Siemens
    > > Communications Limited does = not accept legal responsibility for the
    > > contents of this message. = Any views or opinions presented
    > are solely those
    > > of the author and do not = necessarily represent those of Siemens
    > > Communications Limited = unless otherwise specifically stated.
    > >
    > >
    >

------_=_NextPart_001_01BF851B.5AEDB122-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 3 09:30:27 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28235 for ; Fri, 3 Mar 2000 09:30:26 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8C2B8E40@standards.nortelnetworks.com>; Fri, 3 Mar 2000 9:26:25 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 71271 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Mar 2000 09:25:28 -0500 Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.041EDEE0@standards.nortelnetworks.com>; Fri, 3 Mar 2000 9:15:28 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id PAA29882 for ; Fri, 3 Mar 2000 15:19:03 +0100 (MET) 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 PAA19736 for ; Fri, 3 Mar 2000 15:19:03 +0100 (MET) Received: from ericsson.com (kipe102.eraj.ericsson.se [147.214.68.102]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id PAA23073 for ; Fri, 3 Mar 2000 15:19:02 +0100 (MET) X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38BFC9D5.7CE04967@ericsson.com> Date: Fri, 3 Mar 2000 15:19:01 +0100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: H248 MIB To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day all, What is the status of the Megaco/H248 MIB? Is any body looking after this? Cheers, Christian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 3 09:35:40 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28476 for ; Fri, 3 Mar 2000 09:35:39 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.403B4A10@standards.nortelnetworks.com>; Fri, 3 Mar 2000 9:31:27 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 71291 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Mar 2000 09:31:09 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CF726A30@standards.nortelnetworks.com>; Fri, 3 Mar 2000 9:21:09 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id JAA08245; Fri, 3 Mar 2000 09:24:40 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id JAA18353; Fri, 3 Mar 2000 09:24:43 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id <1WCM1XGG>; Fri, 3 Mar 2000 09:20:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF208A62@whq-msgusr-02.fore.com> Date: Fri, 3 Mar 2000 09:24:25 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt X-To: "mikebuckley@attmail.com" , ITU-SG16@mailbag.cps.intel.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM If this document is stand-alone, not a part of the Megaco document, then it should stand on its merits. The IETF is free, as is the ITU, and any other organization, to define any profile it desires, with any set of options resolved any way it wants. The market will decide if such profiles are worthy. The agreement specifically did NOT include subsequent profiles, packages or other transports, and there are already planned annexes to H.248 which will not have IETF standard status. Please note that while I personally do prefer this profile specifying text, I would make the same argument if someone wanted to define a trunk gateway protocol as binary only. I might try to get that profile defined the other way, but I'd defend the right of the organization to define it binary only if it so chose. In this specific case, you clearly have an issue with code size. If the protocol specifies that both encodings will be implemented, that blows up the code, I would think, unacceptably. If you specify either, you create incompatible systems. Of course, that is the entire problem with the compromise. Brian Brian > -----Original Message----- > From: mikebuckley@attmail.com [mailto:mikebuckley@attmail.com] > Sent: Friday, March 03, 2000 8:35 AM > To: Rosen, Brian; ITU-SG16@mailbag.cps.intel.com > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt > > > I agree wholeheartedly with Keith Drage's comment: > > >Surely it also dishonours the agreement between the ITU-T > and IETF groups, > >as they participated in agreeing the words that go in > H.248/MEGACO, but do > >not apparently participate in discussing the profile that then gets > >subsequently published by IETF. > > This attempt to sidestep the agreement with the ITU can only > create bad faith > between the two organizations. The Megaco wording was > arrived at after lengthy > discussions and compromise on both sides. The consequences > of unilaterally > trying to pursue one line will ony result in the ITU going > off in an incompatible > direction. Is this what the market wants - an IETF package > specifying text > encoding and an ITU Annex specifying binary? > > This is not the way to resolve the text v. binary issue and > it is not the way to built > good relations between the two Standards bodies. > > Agreements should be honoured by both sides in the spirit as > well as the letter. > > Mike Buckley > > > ____________________ Begin Original Message > ___________________________ > Date: Fri Mar 3 08:05:04 -0500 2000 > From: internet!FORE.COM!brosen (Rosen, Brian) > Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt > To: internet!STANDARDS.NORTELNETWORKS.COM!MEGACO > Content-Type: Generic-Text > Content-Length: 5599 > > There are two threads in this message I wish to comment on. > 1. The issue of text encoding. Text/Binary Encoding is defined > in the protocol as optional. A profile could make a choice. > It is acceptable to me that such a choice be made in this profile. > > 2. Subsets of the protocol. I have been vociferous in positing > that profiles cannot subset the protocol. If the protocol > defines something as optional, then the profile can declare > what options shall be implemented. Where there is not an option, > profiles should not make something optional. If it does, it's > a new protocol. Call it that, and we can decide if we want > to standardize a new protocol. I personally do not believe that > an IPPhone needs to subset the Megaco protocol. > > Brian > > > > > -----Original Message----- > > From: Drage, Keith [mailto:Keith.Drage@SIEMENSCOMMS.CO.UK] > > Sent: Friday, March 03, 2000 4:43 AM > > To: MEGACO@standards.nortelnetworks.com > > Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt > > > > > > I note that this proposed profile contains the text: > > > > "Megaco IP Phone MGs MUST support text encoding of the protocol, as > > specified in the Megaco/H.248 Protocol document [3]." > > > > While I DO NOT want to reopen the encoding debate, it seems > > inappropriate to > > me that MEGACO should create a profile that further restricts it own > > product. I understood the summary of the text versus binary > > debate was that > > the decision on encoding would be made by market forces, and was NOT > > application dependent. If there is an application dependency, then > > guidelines to that dependency should surely be given in the > > main MEGACO > > protocol document. > > > > Surely it also dishonours the agreement between the ITU-T and > > IETF groups, > > as they participated in agreeing the words that go in > > H.248/MEGACO, but do > > not apparently participate in discussing the profile that then gets > > subsequently published by IETF. > > > > I would have therefore thought that if TIA wish to restrict > > the encoding > > choice, then it is up to TIA to publish the profile, rather > > than the IETF. > > > > Looking further, I notice that the document also defines > > constraints on the > > usage of Events, etc. Reading the main MEGACO protocol document, I > > understand that variations on termination characteristics should be > > implemented by specification of a package. Should these restrictions > > therefore be defined by a new package? > > > > I guess we need some general discussion on what is possible > > in profiles, as > > opposed to packages, and whether MEGACO should define > > profiles that are > > still nominally called MEGACO, but do not exhibit all the > > requirements of > > the main document. Rephrasing in a slightly different way, > > which are the > > options, and which of these options that are selected based > > on the type of > > application (and therefore suitable for specification in > > profiles for a > > particular application), and which are implementation options > > (and selected > > because an implementor wishes to make his product different > > and presumably > > better/cheaper/fit the available memory than another market > entrant). > > > > Rephrasing the question a different way, with the > > restrictions imposed by > > this "profile", can the result still be MEGACO/H.248, or > has it really > > invented a new protocol? > > > > Let me stress again, I do not want to see any responses that > > it is done this > > way because text is better than binary, or more efficient. > > The answer to > > that is irrelevant to the point I am trying to make. > > > > Keith Drage > > > > > > > --------------------------------------------------------------- > > > Keith Drage (keith.drage@siemenscomms.co.uk) > > > Siemens Communications Limited, > > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > > --------------------------------------------------------------- > > > Internet communications are not secure and therefore Siemens > > > Communications Limited does not accept legal > responsibility for the > > > contents of this message. Any views or opinions presented > are solely > > > those of the author and do not necessarily represent those > > of Siemens > > > Communications Limited unless otherwise specifically stated. > > > > > > 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 IP Phone Media Gateway > > > Application Profile > > > Author(s) : R. Bell, P. Blatherwick, P. Holland > > > Filename : draft-ietf-megaco-ipphone-02.txt > > > Pages : 13 > > > Date : 01-Mar-00 > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-ietf-megaco-ipphone-02.txt > > > > > > > > > > --------------------------------------------------------------- > > > Keith Drage (keith.drage@siemenscomms.co.uk) > > > Siemens Communications Limited, > > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > > --------------------------------------------------------------- > > > Internet communications are not secure and therefore Siemens > > > Communications Limited does not accept legal > responsibility for the > > > contents of this message. Any views or opinions presented > > are solely those > > > of the author and do not necessarily represent those of Siemens > > > Communications Limited unless otherwise specifically stated. > > > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 3 09:39:42 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28679 for ; Fri, 3 Mar 2000 09:39:41 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D0E9B600@standards.nortelnetworks.com>; Fri, 3 Mar 2000 9:35:30 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 71298 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Mar 2000 09:34:59 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.589A4300@standards.nortelnetworks.com>; Fri, 3 Mar 2000 9:24:59 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id JAA08684; Fri, 3 Mar 2000 09:28:32 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id JAA19296; Fri, 3 Mar 2000 09:28:35 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id <1WCM1XJM>; Fri, 3 Mar 2000 09:24:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF851C.335B7AF8" Message-ID: <4FBEA8857476D311A03300204840E1CF208A63@whq-msgusr-02.fore.com> Date: Fri, 3 Mar 2000 09:28:19 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt X-To: Tom-PT Taylor 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_01BF851C.335B7AF8 Content-Type: text/plain; charset="iso-8859-1" I personally don't think we need go quite as far as Tom does in 1, but I'm willing to compromise. I'd think informational is appropriate for this document. I'd think that any package/profile would be best left as informational, at least for some time. At some point in the future, we could consider doing a standards track set of additional packages. I'm not sure that there will ever be a need to do a standards track profile - I really expect most profiles to be defined outside of either IETF or ITU. Brian -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Friday, March 03, 2000 9:19 AM To: MEGACO@standards.nortelnetworks.com Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt One of the key issues is what the Working Group wishes to do with the IP Phone document. I'd say the choices are these, but I'm being a little arbitrary here: (1) The document is Standards Track and is an official Megaco output. In that case, I think it should conform entirely to the spirit of the main protocol document (i.e. I'll concede Mike and Keith's points). I will point out that the main protocol document does NOT require an MG to support a specific encoding. (2) The document is Informational and is an official Megaco output. In that case, I think it should conform to the position as stated by Brian. We have the right to select from options, but not to modify the actual protocol we have produced. (3) The document is not an official Megaco output. In that case, the TIA has the right to publish what they want, subject to IESG approval. Of course, the IESG may refer it to us for comment. -----Original Message----- From: Mike Buckley [SMTP:mikebuckley@ATTMAIL.COM] Sent: Friday, March 03, 2000 8:35 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt I agree wholeheartedly with Keith Drage's comment: >Surely it also dishonours the agreement between the ITU-T and IETF groups, >as they participated in agreeing the words that go in H.248/MEGACO, but do >not apparently participate in discussing the profile that then gets >subsequently published by IETF. This attempt to sidestep the agreement with the ITU can only create bad faith between the two organizations. The Megaco wording was arrived at after lengthy discussions and compromise on both sides. The consequences of unilaterally trying to pursue one line will ony result in the ITU going off in an incompatible direction. Is this what the market wants - an IETF package specifying text encoding and an ITU Annex specifying binary? This is not the way to resolve the text v. binary issue and it is not the way to built good relations between the two Standards bodies. Agreements should be honoured by both sides in the spirit as well as the letter. Mike Buckley ____________________ Begin Original Message ___________________________ Date: Fri Mar 3 08:05:04 -0500 2000 From: internet!FORE.COM!brosen (Rosen, Brian) Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt To: internet!STANDARDS.NORTELNETWORKS.COM!MEGACO Content-Type: Generic-Text Content-Length: 5599 There are two threads in this message I wish to comment on. 1. The issue of text encoding. Text/Binary Encoding is defined in the protocol as optional. A profile could make a choice. It is acceptable to me that such a choice be made in this profile. 2. Subsets of the protocol. I have been vociferous in positing that profiles cannot subset the protocol. If the protocol defines something as optional, then the profile can declare what options shall be implemented. Where there is not an option, profiles should not make something optional. If it does, it's a new protocol. Call it that, and we can decide if we want to standardize a new protocol. I personally do not believe that an IPPhone needs to subset the Megaco protocol. Brian > -----Original Message----- > From: Drage, Keith [ mailto:Keith.Drage@SIEMENSCOMMS.CO.UK ] > Sent: Friday, March 03, 2000 4:43 AM > To: MEGACO@standards.nortelnetworks.com > Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt > > > I note that this proposed profile contains the text: > > "Megaco IP Phone MGs MUST support text encoding of the protocol, as > specified in the Megaco/H.248 Protocol document [3]." > > While I DO NOT want to reopen the encoding debate, it seems > inappropriate to > me that MEGACO should create a profile that further restricts it own > product. I understood the summary of the text versus binary > debate was that > the decision on encoding would be made by market forces, and was NOT > application dependent. If there is an application dependency, then > guidelines to that dependency should surely be given in the > main MEGACO > protocol document. > > Surely it also dishonours the agreement between the ITU-T and > IETF groups, > as they participated in agreeing the words that go in > H.248/MEGACO, but do > not apparently participate in discussing the profile that then gets > subsequently published by IETF. > > I would have therefore thought that if TIA wish to restrict > the encoding > choice, then it is up to TIA to publish the profile, rather > than the IETF. > > Looking further, I notice that the document also defines > constraints on the > usage of Events, etc. Reading the main MEGACO protocol document, I > understand that variations on termination characteristics should be > implemented by specification of a package. Should these restrictions > therefore be defined by a new package? > > I guess we need some general discussion on what is possible > in profiles, as > opposed to packages, and whether MEGACO should define > profiles that are > still nominally called MEGACO, but do not exhibit all the > requirements of > the main document. Rephrasing in a slightly different way, > which are the > options, and which of these options that are selected based > on the type of > application (and therefore suitable for specification in > profiles for a > particular application), and which are implementation options > (and selected > because an implementor wishes to make his product different > and presumably > better/cheaper/fit the available memory than another market entrant). > > Rephrasing the question a different way, with the > restrictions imposed by > this "profile", can the result still be MEGACO/H.248, or has it really > invented a new protocol? > > Let me stress again, I do not want to see any responses that > it is done this > way because text is better than binary, or more efficient. > The answer to > that is irrelevant to the point I am trying to make. > > Keith Drage > > > > --------------------------------------------------------------- > > Keith Drage (keith.drage@siemenscomms.co.uk) > > Siemens Communications Limited, > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > --------------------------------------------------------------- > > Internet communications are not secure and therefore Siemens > > Communications Limited does not accept legal responsibility for the > > contents of this message. Any views or opinions presented are solely > > those of the author and do not necessarily represent those > of Siemens > > Communications Limited unless otherwise specifically stated. > > > > 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 IP Phone Media Gateway > > Application Profile > > Author(s) : R. Bell, P. Blatherwick, P. Holland > > Filename : draft-ietf-megaco-ipphone-02.txt > > Pages : 13 > > Date : 01-Mar-00 > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-megaco-ipphone-02.txt > > > > > > --------------------------------------------------------------- > > Keith Drage (keith.drage@siemenscomms.co.uk) > > Siemens Communications Limited, > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > --------------------------------------------------------------- > > Internet communications are not secure and therefore Siemens > > Communications Limited does not accept legal responsibility for the > > contents of this message. Any views or opinions presented > are solely those > > of the author and do not necessarily represent those of Siemens > > Communications Limited unless otherwise specifically stated. > > > > > ------_=_NextPart_001_01BF851C.335B7AF8 Content-Type: text/html; charset="iso-8859-1" RE: I-D ACTION:draft-ietf-megaco-ipphone-02.txt
I personally don't think we need go quite as far as Tom does in 1, but I'm willing
to compromise.
 
I'd think informational is appropriate for this document.  I'd think that any package/profile
would be best left as informational, at least for some time.  At some point in the future,
we could consider doing a standards track set of additional packages.  I'm not sure that
there will ever be a need to do a standards track profile - I really expect most profiles
to be defined outside of either IETF or ITU.
 
Brian
-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Friday, March 03, 2000 9:19 AM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt

One of the key issues is what the Working Group wishes to do with the IP Phone document.  I'd say the choices are these, but I'm being a little arbitrary here:

  (1) The document is Standards Track and is an official Megaco output.  In that case, I think it should conform entirely to the spirit of the main protocol document (i.e. I'll concede Mike and Keith's points).  I will point out that the main protocol document does NOT require an MG to support a specific encoding.

  (2) The document is Informational and is an official Megaco output.  In that case, I think it should conform to the position as stated by Brian.  We have the right to select from options, but not to modify the actual protocol we have produced.

  (3) The document is not an official Megaco output.  In that case, the TIA has the right to publish what they want, subject to IESG  approval.  Of course, the IESG may refer it to us for comment.

    -----Original Message-----
    From:   Mike Buckley [SMTP:mikebuckley@ATTMAIL.COM]
    Sent:   Friday, March 03, 2000 8:35 AM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:        Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt

    I agree wholeheartedly with Keith Drage's comment:

    >Surely it also dishonours the agreement between the ITU-T and IETF groups,
    >as they participated in agreeing the words that go in H.248/MEGACO, but do
    >not apparently participate in discussing the profile that then gets
    >subsequently published by IETF.

    This attempt to sidestep the agreement with the ITU can only create bad faith
    between the two organizations.  The Megaco wording was arrived at after lengthy
    discussions and compromise on both sides.  The consequences of unilaterally
    trying to pursue one line will ony result in the ITU going off in an incompatible
    direction.  Is this what the market wants - an IETF package specifying text
    encoding and an ITU Annex specifying binary?

    This is not the way to resolve the text v. binary issue and it is not the way to built
    good relations between the two Standards bodies.

    Agreements should be honoured by both sides in the spirit as well as the letter.

    Mike Buckley


    ____________________ Begin Original Message
    ___________________________
    Date: Fri Mar  3 08:05:04 -0500 2000
    From: internet!FORE.COM!brosen (Rosen, Brian)
    Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt
    To: internet!STANDARDS.NORTELNETWORKS.COM!MEGACO
    Content-Type: Generic-Text
    Content-Length: 5599

    There are two threads in this message I wish to comment on.
    1. The issue of text encoding.  Text/Binary Encoding is defined
    in the protocol as optional. A profile could make a choice.
    It is acceptable to me that such a choice be made in this profile.

    2. Subsets of the protocol.  I have been vociferous in positing
    that profiles cannot subset the protocol.  If the protocol
    defines something as optional, then the profile can declare
    what options shall be implemented.  Where there is not an option,
    profiles should not make something optional.  If it does, it's
    a new protocol.  Call it that, and we can decide if we want
    to standardize a new protocol.  I personally do not believe that
    an IPPhone needs to subset the Megaco protocol.

    Brian



    > -----Original Message-----
    > From: Drage, Keith [mailto:Keith.Drage@SIEMENSCOMMS.CO.UK]
    > Sent: Friday, March 03, 2000 4:43 AM
    > To: MEGACO@standards.nortelnetworks.com
    > Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt
    >
    >
    > I note that this proposed profile contains the text:
    >
    > "Megaco IP Phone MGs MUST support text encoding of the protocol, as
    > specified in the Megaco/H.248 Protocol document [3]."
    >
    > While I DO NOT want to reopen the encoding debate, it seems
    > inappropriate to
    > me that MEGACO should create a profile that further restricts it own
    > product. I understood the summary of the text versus binary
    > debate was that
    > the decision on encoding would be made by market forces, and was NOT
    > application dependent. If there is an application dependency, then
    > guidelines to that dependency should surely be given in the
    > main MEGACO
    > protocol document.
    >
    > Surely it also dishonours the agreement between the ITU-T and
    > IETF groups,
    > as they participated in agreeing the words that go in
    > H.248/MEGACO, but do
    > not apparently participate in discussing the profile that then gets
    > subsequently published by IETF.
    >
    > I would have therefore thought that if TIA wish to restrict
    > the encoding
    > choice, then it is up to TIA to publish the profile, rather
    > than the IETF.
    >
    > Looking further, I notice that the document also defines
    > constraints on the
    > usage of Events, etc. Reading the main MEGACO protocol document, I
    > understand that variations on termination characteristics should be
    > implemented by specification of a package. Should these restrictions
    > therefore be defined by a new package?
    >
    > I guess we need some general discussion on what is possible
    > in profiles, as
    > opposed to packages, and whether MEGACO should define
    > profiles that are
    > still nominally called MEGACO, but do not exhibit all the
    > requirements of
    > the main document. Rephrasing in a slightly different way,
    > which are the
    > options, and which of these options that are selected based
    > on the type of
    > application (and therefore suitable for specification in
    > profiles for a
    > particular application), and which are implementation options
    > (and selected
    > because an implementor wishes to make his product different
    > and presumably
    > better/cheaper/fit the available memory than another market entrant).
    >
    > Rephrasing the question a different way, with the
    > restrictions imposed by
    > this "profile", can the result still be MEGACO/H.248, or has it really
    > invented a new protocol?
    >
    > Let me stress again, I do not want to see any responses that
    > it is done this
    > way because text is better than binary, or more efficient.
    > The answer to
    > that is irrelevant to the point I am trying to make.
    >
    > Keith Drage
    >
    >
    > > ---------------------------------------------------------------
    > > Keith Drage (keith.drage@siemenscomms.co.uk)
    > > Siemens Communications Limited,
    > > Technology Drive, Beeston, Nottingham NG9 1LA, UK
    > > Tel: +44 115 943 4991   Fax: +44 115 943 4992
    > > ---------------------------------------------------------------
    > > Internet communications are not secure and therefore Siemens
    > > Communications Limited does not accept legal responsibility for the
    > > contents of this message. Any views or opinions presented are solely
    > > those of the author and do not necessarily represent those
    > of Siemens
    > > Communications Limited unless otherwise specifically stated.
    > >
    > > 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 IP Phone Media Gateway
    > > Application Profile
    > >         Author(s)       : R. Bell,  P. Blatherwick, P. Holland
    > >         Filename        : draft-ietf-megaco-ipphone-02.txt
    > >         Pages           : 13
    > >         Date            : 01-Mar-00
    > >
    > > A URL for this Internet-Draft is:
    > > http://www.ietf.org/internet-drafts/draft-ietf-megaco-ipphone-02.txt
    > >
    >
    >
    > > ---------------------------------------------------------------
    > > Keith Drage (keith.drage@siemenscomms.co.uk)
    > > Siemens Communications Limited,
    > > Technology Drive, Beeston, Nottingham NG9 1LA, UK
    > > Tel: +44 115 943 4991   Fax: +44 115 943 4992
    > > ---------------------------------------------------------------
    > > Internet communications are not secure and therefore Siemens
    > > Communications Limited does not accept legal responsibility for the
    > > contents of this message. Any views or opinions presented
    > are solely those
    > > of the author and do not necessarily represent those of Siemens
    > > Communications Limited unless otherwise specifically stated.
    > >
    > >
    >

------_=_NextPart_001_01BF851C.335B7AF8-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 3 09:48:40 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28872 for ; Fri, 3 Mar 2000 09:48:39 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.14D87FD0@standards.nortelnetworks.com>; Fri, 3 Mar 2000 9:44:34 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 71394 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Mar 2000 09:42:52 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D83E9550@standards.nortelnetworks.com>; Fri, 3 Mar 2000 9:42:52 -0500 Received: from zmers013 by smtprch1.nortel.com; Fri, 3 Mar 2000 08:45:55 -0600 Received: from zrchb213.us.nortel.com (actually zrchb213) by zmers013; Fri, 3 Mar 2000 09:45:21 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Mar 2000 08:45:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF851F.16DEA0B4" Message-ID: Date: Fri, 3 Mar 2000 08:45:17 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: H248 MIB X-To: Christian Groves 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_01BF851F.16DEA0B4 Content-Type: text/plain Matt Holdrege is editor. He is eagerly awaiting your comments. > -----Original Message----- > From: Christian Groves [SMTP:Christian.Groves@ERICSSON.COM] > Sent: Friday, March 03, 2000 9:19 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: H248 MIB > > G'Day all, > > What is the status of the Megaco/H248 MIB? Is any body looking after > this? > > Cheers, Christian ------_=_NextPart_001_01BF851F.16DEA0B4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: H248 MIB

Matt Holdrege is = editor.  He is eagerly awaiting your comments.

    -----Original Message-----
    From:   Christian Groves = [SMTP:Christian.Groves@ERICSSON.COM]
    Sent:   Friday, March 03, 2000 9:19 AM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = H248 MIB

    G'Day all,

    What is the status of the Megaco/H248 = MIB? Is any body looking after
    this?

    Cheers, Christian

------_=_NextPart_001_01BF851F.16DEA0B4-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 3 19:41:47 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12636 for ; Fri, 3 Mar 2000 19:41:46 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EFBEBBD0@standards.nortelnetworks.com>; Fri, 3 Mar 2000 19:37:40 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 72183 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 3 Mar 2000 19:36:22 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C15182A0@standards.nortelnetworks.com>; Fri, 3 Mar 2000 19:36:22 -0500 Received: from zmers013 by smtprch1.nortel.com; Fri, 3 Mar 2000 18:39:35 -0600 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by zmers013; Fri, 3 Mar 2000 19:38:58 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 3 Mar 2000 19:38:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8572.064D1868" Message-ID: <29400B68197CD31188830000F8CD15D343BC7D@zcard00q.ca.nortel.com> Date: Fri, 3 Mar 2000 19:38:54 -0500 Reply-To: Peter Blatherwick Sender: "Media Gateway Control (megaco)" From: Peter Blatherwick Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt X-To: "Drage, Keith" , Mike Buckley 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_01BF8572.064D1868 Content-Type: text/plain; charset="iso-8859-1" Keith, Mike, others, It is very definitely NOT our intent to create friction between ITU and IETF in our extremely admirable co-operative effort on the H.248/Megaco protocol. It is also not our intent to set any constraints or precedents on how other applications of the protocol work, whether these applications are defined in IETF, ITU or elsewhere. This is in no way an attempt to side-step agreed process. Our intent is to define a particular application of the protocol, primarily targeted at creating cost-optimized embedded devices. In this specific case, as with other very small scale applications, a choice on both encoding and transport absolutely must be made, to reduce memory footprint. (We would like to see other reductions as well, but let's talk about that separately.) We chose text encoding since it seems to us more easily and compactly implementable for this particular application. The transport selection (ALF) was decided for similar pragmatic reasons. This does not necessarily reflect on any other application. It may well be that we are wrong on these choices, but a decision has to be made to move forward. As Brian has already noted, these are both options in the protocol at the MG side. Note also that the profile does not restrict use of binary encoding as well as text, just that the text encoding must be implemented. The same logic applies to transport. The point that we must decide where to settle definition of this and other applications/profiles is well taken, and I agree its at the core of the debate. However, I personally believe it is important to settle some specific applications of the protocol soon, leading towards interoperability testing and validation, which are natural parts of the IETF side of the joint process. Then again, I'm no process guru... I hope that helps, and apologize for not making it more clear up front. Peter Blatherwick > -----Original Message----- > From: Mike Buckley [SMTP:mikebuckley@ATTMAIL.COM] > Sent: Friday, March 03, 2000 8:35 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt > > I agree wholeheartedly with Keith Drage's comment: > > >Surely it also dishonours the agreement between the ITU-T and IETF > groups, > >as they participated in agreeing the words that go in H.248/MEGACO, but > do > >not apparently participate in discussing the profile that then gets > >subsequently published by IETF. > > This attempt to sidestep the agreement with the ITU can only create bad > faith > between the two organizations. The Megaco wording was arrived at after > lengthy > discussions and compromise on both sides. The consequences of > unilaterally > trying to pursue one line will ony result in the ITU going off in an > incompatible > direction. Is this what the market wants - an IETF package specifying > text > encoding and an ITU Annex specifying binary? > > This is not the way to resolve the text v. binary issue and it is not the > way to built > good relations between the two Standards bodies. > > Agreements should be honoured by both sides in the spirit as well as the > letter. > > Mike Buckley > > > ____________________ Begin Original Message > ___________________________ > Date: Fri Mar 3 08:05:04 -0500 2000 > From: internet!FORE.COM!brosen (Rosen, Brian) > Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt > To: internet!STANDARDS.NORTELNETWORKS.COM!MEGACO > Content-Type: Generic-Text > Content-Length: 5599 > > There are two threads in this message I wish to comment on. > 1. The issue of text encoding. Text/Binary Encoding is defined > in the protocol as optional. A profile could make a choice. > It is acceptable to me that such a choice be made in this profile. > > 2. Subsets of the protocol. I have been vociferous in positing > that profiles cannot subset the protocol. If the protocol > defines something as optional, then the profile can declare > what options shall be implemented. Where there is not an option, > profiles should not make something optional. If it does, it's > a new protocol. Call it that, and we can decide if we want > to standardize a new protocol. I personally do not believe that > an IPPhone needs to subset the Megaco protocol. > > Brian > > > > > -----Original Message----- > > From: Drage, Keith [mailto:Keith.Drage@SIEMENSCOMMS.CO.UK] > > Sent: Friday, March 03, 2000 4:43 AM > > To: MEGACO@standards.nortelnetworks.com > > Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt > > > > > > I note that this proposed profile contains the text: > > > > "Megaco IP Phone MGs MUST support text encoding of the protocol, as > > specified in the Megaco/H.248 Protocol document [3]." > > > > While I DO NOT want to reopen the encoding debate, it seems > > inappropriate to > > me that MEGACO should create a profile that further restricts it own > > product. I understood the summary of the text versus binary > > debate was that > > the decision on encoding would be made by market forces, and was NOT > > application dependent. If there is an application dependency, then > > guidelines to that dependency should surely be given in the > > main MEGACO > > protocol document. > > > > Surely it also dishonours the agreement between the ITU-T and > > IETF groups, > > as they participated in agreeing the words that go in > > H.248/MEGACO, but do > > not apparently participate in discussing the profile that then gets > > subsequently published by IETF. > > > > I would have therefore thought that if TIA wish to restrict > > the encoding > > choice, then it is up to TIA to publish the profile, rather > > than the IETF. > > > > Looking further, I notice that the document also defines > > constraints on the > > usage of Events, etc. Reading the main MEGACO protocol document, I > > understand that variations on termination characteristics should be > > implemented by specification of a package. Should these restrictions > > therefore be defined by a new package? > > > > I guess we need some general discussion on what is possible > > in profiles, as > > opposed to packages, and whether MEGACO should define > > profiles that are > > still nominally called MEGACO, but do not exhibit all the > > requirements of > > the main document. Rephrasing in a slightly different way, > > which are the > > options, and which of these options that are selected based > > on the type of > > application (and therefore suitable for specification in > > profiles for a > > particular application), and which are implementation options > > (and selected > > because an implementor wishes to make his product different > > and presumably > > better/cheaper/fit the available memory than another market entrant). > > > > Rephrasing the question a different way, with the > > restrictions imposed by > > this "profile", can the result still be MEGACO/H.248, or has it really > > invented a new protocol? > > > > Let me stress again, I do not want to see any responses that > > it is done this > > way because text is better than binary, or more efficient. > > The answer to > > that is irrelevant to the point I am trying to make. > > > > Keith Drage > > > > > > > --------------------------------------------------------------- > > > Keith Drage (keith.drage@siemenscomms.co.uk) > > > Siemens Communications Limited, > > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > > --------------------------------------------------------------- > > > Internet communications are not secure and therefore Siemens > > > Communications Limited does not accept legal responsibility for the > > > contents of this message. Any views or opinions presented are solely > > > those of the author and do not necessarily represent those > > of Siemens > > > Communications Limited unless otherwise specifically stated. > > > > > > 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 IP Phone Media Gateway > > > Application Profile > > > Author(s) : R. Bell, P. Blatherwick, P. Holland > > > Filename : draft-ietf-megaco-ipphone-02.txt > > > Pages : 13 > > > Date : 01-Mar-00 > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-megaco-ipphone-02.txt > > > > > > > > > > --------------------------------------------------------------- > > > Keith Drage (keith.drage@siemenscomms.co.uk) > > > Siemens Communications Limited, > > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > > --------------------------------------------------------------- > > > Internet communications are not secure and therefore Siemens > > > Communications Limited does not accept legal responsibility for the > > > contents of this message. Any views or opinions presented > > are solely those > > > of the author and do not necessarily represent those of Siemens > > > Communications Limited unless otherwise specifically stated. > > > > > > > > ------_=_NextPart_001_01BF8572.064D1868 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-megaco-ipphone-02.txt

Keith, Mike, = others,

It is very = definitely NOT our intent to create friction between ITU and IETF in = our extremely admirable co-operative effort on the H.248/Megaco = protocol.  It is also not our intent to set any constraints or = precedents on how other applications of the protocol work, whether = these applications are defined in IETF, ITU or elsewhere.  This is = in no way an attempt to side-step agreed process. 

Our intent is to = define a particular application of the protocol, primarily targeted at = creating cost-optimized embedded devices.  In this specific case, = as with other very small scale applications, a choice on both encoding = and transport absolutely must be made, to reduce memory = footprint.  (We would like to see other reductions as well, but = let's talk about that separately.)  We chose text encoding since = it seems to us more easily and compactly implementable for this = particular application.  The transport selection (ALF) was decided = for similar pragmatic reasons.  This does not necessarily reflect = on any other application.  It may well be that we are wrong on = these choices, but a decision has to be made to move forward.  =

As Brian has already = noted, these are both options in the protocol at the MG side.  = Note also that the profile does not restrict use of binary encoding as = well as text, just that the text encoding must be implemented.  = The same logic applies to transport. 

The point that we = must decide where to settle definition of this and other = applications/profiles is well taken, and I agree its at the core of the = debate.  However, I personally believe it is important to settle = some specific applications of the protocol soon, leading towards = interoperability testing and validation, which are natural parts of the = IETF side of the joint process.  Then again, I'm no process = guru...   

I hope that helps, = and apologize for not making it more clear up front. 

Peter = Blatherwick

    -----Original Message-----
    From:   Mike Buckley = [SMTP:mikebuckley@ATTMAIL.COM]
    Sent:   Friday, March 03, 2000 8:35 AM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: I-D = ACTION:draft-ietf-megaco-ipphone-02.txt

    I agree wholeheartedly with Keith = Drage's comment:

    >Surely it also dishonours the = agreement between the ITU-T and IETF groups,
    >as they participated in agreeing = the words that go in H.248/MEGACO, but do
    >not apparently participate in = discussing the profile that then gets
    >subsequently published by = IETF.

    This attempt to sidestep the agreement = with the ITU can only create bad faith
    between the two organizations.  = The Megaco wording was arrived at after lengthy
    discussions and compromise on both = sides.  The consequences of unilaterally
    trying to pursue one line will ony = result in the ITU going off in an incompatible
    direction.  Is this what the = market wants - an IETF package specifying text
    encoding and an ITU Annex specifying = binary?

    This is not the way to resolve the = text v. binary issue and it is not the way to built
    good relations between the two = Standards bodies.

    Agreements should be honoured by both = sides in the spirit as well as the letter.

    Mike Buckley


    ____________________ Begin Original = Message
    ___________________________
    Date: Fri Mar  3 08:05:04 -0500 = 2000
    From: internet!FORE.COM!brosen = (Rosen, Brian)
    Subject: Re: I-D = ACTION:draft-ietf-megaco-ipphone-02.txt
    To: = internet!STANDARDS.NORTELNETWORKS.COM!MEGACO
    Content-Type: Generic-Text
    Content-Length: 5599

    There are two threads in this message = I wish to comment on.
    1. The issue of text encoding.  = Text/Binary Encoding is defined
    in the protocol as optional. A = profile could make a choice.
    It is acceptable to me that such a = choice be made in this profile.

    2. Subsets of the protocol.  I = have been vociferous in positing
    that profiles cannot subset the = protocol.  If the protocol
    defines something as optional, then = the profile can declare
    what options shall be = implemented.  Where there is not an option,
    profiles should not make something = optional.  If it does, it's
    a new protocol.  Call it that, = and we can decide if we want
    to standardize a new protocol.  = I personally do not believe that
    an IPPhone needs to subset the Megaco = protocol.

    Brian



    > -----Original Message-----
    > From: Drage, Keith = [mailto:Keith.Drage@SIEMEN= SCOMMS.CO.UK]
    > Sent: Friday, March 03, 2000 = 4:43 AM
    > To: = MEGACO@standards.nortelnetworks.com
    > Subject: Re: I-D = ACTION:draft-ietf-megaco-ipphone-02.txt
    >
    >
    > I note that this proposed = profile contains the text:
    >
    > "Megaco IP Phone MGs MUST = support text encoding of the protocol, as
    > specified in the Megaco/H.248 = Protocol document [3]."
    >
    > While I DO NOT want to reopen = the encoding debate, it seems
    > inappropriate to
    > me that MEGACO should create a = profile that further restricts it own
    > product. I understood the = summary of the text versus binary
    > debate was that
    > the decision on encoding would = be made by market forces, and was NOT
    > application dependent. If there = is an application dependency, then
    > guidelines to that dependency = should surely be given in the
    > main MEGACO
    > protocol document.
    >
    > Surely it also dishonours the = agreement between the ITU-T and
    > IETF groups,
    > as they participated in agreeing = the words that go in
    > H.248/MEGACO, but do
    > not apparently participate in = discussing the profile that then gets
    > subsequently published by = IETF.
    >
    > I would have therefore thought = that if TIA wish to restrict
    > the encoding
    > choice, then it is up to TIA to = publish the profile, rather
    > than the IETF.
    >
    > Looking further, I notice that = the document also defines
    > constraints on the
    > usage of Events, etc. Reading = the main MEGACO protocol document, I
    > understand that variations on = termination characteristics should be
    > implemented by specification of = a package. Should these restrictions
    > therefore be defined by a new = package?
    >
    > I guess we need some general = discussion on what is possible
    > in profiles, as
    > opposed to packages, and whether = MEGACO should define
    > profiles that are
    > still nominally called MEGACO, = but do not exhibit all the
    > requirements of
    > the main document. Rephrasing in = a slightly different way,
    > which are the
    > options, and which of these = options that are selected based
    > on the type of
    > application (and therefore = suitable for specification in
    > profiles for a
    > particular application), and = which are implementation options
    > (and selected
    > because an implementor wishes to = make his product different
    > and presumably
    > better/cheaper/fit the available = memory than another market entrant).
    >
    > Rephrasing the question a = different way, with the
    > restrictions imposed by
    > this "profile", can = the result still be MEGACO/H.248, or has it really
    > invented a new protocol?
    >
    > Let me stress again, I do not = want to see any responses that
    > it is done this
    > way because text is better than = binary, or more efficient.
    > The answer to
    > that is irrelevant to the point = I am trying to make.
    >
    > Keith Drage
    >
    >
    > > = ---------------------------------------------------------------
    > > Keith Drage = (keith.drage@siemenscomms.co.uk)
    > > Siemens Communications = Limited,
    > > Technology Drive, Beeston, = Nottingham NG9 1LA, UK
    > > Tel: +44 115 943 = 4991   Fax: +44 115 943 4992
    > > = ---------------------------------------------------------------
    > > Internet communications are = not secure and therefore Siemens
    > > Communications Limited does = not accept legal responsibility for the
    > > contents of this message. = Any views or opinions presented are solely
    > > those of the author and do = not necessarily represent those
    > of Siemens
    > > Communications Limited = unless otherwise specifically stated.
    > >
    > > 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 IP Phone Media Gateway
    > > Application Profile
    > = >         = Author(s)       : R. Bell,  P. = Blatherwick, P. Holland
    > = >         = Filename        : = draft-ietf-megaco-ipphone-02.txt
    > = >         = Pages           : = 13
    > = >         = Date            = : 01-Mar-00
    > >
    > > A URL for this = Internet-Draft is:
    > > http://www.ietf.org/internet-drafts/draft-ietf-megaco-= ipphone-02.txt
    > >
    >
    >
    > > = ---------------------------------------------------------------
    > > Keith Drage (keith.drage@sie= menscomms.co.uk)
    > > Siemens Communications = Limited,
    > > Technology Drive, Beeston, = Nottingham NG9 1LA, UK
    > > Tel: +44 115 943 = 4991   Fax: +44 115 943 4992
    > > = ---------------------------------------------------------------
    > > Internet communications are = not secure and therefore Siemens
    > > Communications Limited does = not accept legal responsibility for the
    > > contents of this message. = Any views or opinions presented
    > are solely those
    > > of the author and do not = necessarily represent those of Siemens
    > > Communications Limited = unless otherwise specifically stated.
    > >
    > >
    >

------_=_NextPart_001_01BF8572.064D1868-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Mar 5 21:08:25 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13598 for ; Sun, 5 Mar 2000 21:08:25 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.58412E50@standards.nortelnetworks.com>; 5 Mar 2000 21:04:07 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 74067 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 5 Mar 2000 21:02:44 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.268F2A60@standards.nortelnetworks.com>; 5 Mar 2000 21:02:43 -0500 Received: from chsharp-tecra (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id SAA03651; Sun, 5 Mar 2000 18:06:21 -0800 (PST) X-Sender: chsharp@localhost.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.2.2.20000306104837.00ca9100@localhost.cisco.com> Date: Mon, 6 Mar 2000 10:53:05 -0800 Reply-To: Chip Sharp Sender: "Media Gateway Control (megaco)" From: Chip Sharp Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt X-To: Mike Buckley To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: At 01:35 PM 3/3/00 +0000, Mike Buckley wrote: >I agree wholeheartedly with Keith Drage's comment: > > >Surely it also dishonours the agreement between the ITU-T and IETF groups, > >as they participated in agreeing the words that go in H.248/MEGACO, but do > >not apparently participate in discussing the profile that then gets > >subsequently published by IETF. > >This attempt to sidestep the agreement with the ITU can only create bad faith >between the two organizations. The Megaco wording was arrived at after >lengthy >discussions and compromise on both sides. The consequences of unilaterally >trying to pursue one line will ony result in the ITU going off in an >incompatible >direction. Is this what the market wants - an IETF package specifying text >encoding and an ITU Annex specifying binary?' The protocol was structured such that additional packages could be defined by interested groups based on the base protocol. The ITU has initiated additional packages that the IETF will not standardize and vice versa. I assume that I can depend on everyone to stand up and defend text encoding if Study Group 11 mandates binary encoding for BICC's use of H.248 in the interest of harmony? ;-) I tend to believe either a profile or package should only define options to be used, but shouldn't modify base operation of the protocol. >This is not the way to resolve the text v. binary issue and it is not the >way to built >good relations between the two Standards bodies. > >Agreements should be honoured by both sides in the spirit as well as the >letter. > >Mike Buckley > > >____________________ Begin Original Message >___________________________ >Date: Fri Mar 3 08:05:04 -0500 2000 >From: internet!FORE.COM!brosen (Rosen, Brian) >Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt >To: internet!STANDARDS.NORTELNETWORKS.COM!MEGACO >Content-Type: Generic-Text >Content-Length: 5599 > >There are two threads in this message I wish to comment on. >1. The issue of text encoding. Text/Binary Encoding is defined >in the protocol as optional. A profile could make a choice. >It is acceptable to me that such a choice be made in this profile. > >2. Subsets of the protocol. I have been vociferous in positing >that profiles cannot subset the protocol. If the protocol >defines something as optional, then the profile can declare >what options shall be implemented. Where there is not an option, >profiles should not make something optional. If it does, it's >a new protocol. Call it that, and we can decide if we want >to standardize a new protocol. I personally do not believe that >an IPPhone needs to subset the Megaco protocol. > >Brian > > > > > -----Original Message----- > > From: Drage, Keith [mailto:Keith.Drage@SIEMENSCOMMS.CO.UK] > > Sent: Friday, March 03, 2000 4:43 AM > > To: MEGACO@standards.nortelnetworks.com > > Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt > > > > > > I note that this proposed profile contains the text: > > > > "Megaco IP Phone MGs MUST support text encoding of the protocol, as > > specified in the Megaco/H.248 Protocol document [3]." > > > > While I DO NOT want to reopen the encoding debate, it seems > > inappropriate to > > me that MEGACO should create a profile that further restricts it own > > product. I understood the summary of the text versus binary > > debate was that > > the decision on encoding would be made by market forces, and was NOT > > application dependent. If there is an application dependency, then > > guidelines to that dependency should surely be given in the > > main MEGACO > > protocol document. > > > > Surely it also dishonours the agreement between the ITU-T and > > IETF groups, > > as they participated in agreeing the words that go in > > H.248/MEGACO, but do > > not apparently participate in discussing the profile that then gets > > subsequently published by IETF. > > > > I would have therefore thought that if TIA wish to restrict > > the encoding > > choice, then it is up to TIA to publish the profile, rather > > than the IETF. > > > > Looking further, I notice that the document also defines > > constraints on the > > usage of Events, etc. Reading the main MEGACO protocol document, I > > understand that variations on termination characteristics should be > > implemented by specification of a package. Should these restrictions > > therefore be defined by a new package? > > > > I guess we need some general discussion on what is possible > > in profiles, as > > opposed to packages, and whether MEGACO should define > > profiles that are > > still nominally called MEGACO, but do not exhibit all the > > requirements of > > the main document. Rephrasing in a slightly different way, > > which are the > > options, and which of these options that are selected based > > on the type of > > application (and therefore suitable for specification in > > profiles for a > > particular application), and which are implementation options > > (and selected > > because an implementor wishes to make his product different > > and presumably > > better/cheaper/fit the available memory than another market entrant). > > > > Rephrasing the question a different way, with the > > restrictions imposed by > > this "profile", can the result still be MEGACO/H.248, or has it really > > invented a new protocol? > > > > Let me stress again, I do not want to see any responses that > > it is done this > > way because text is better than binary, or more efficient. > > The answer to > > that is irrelevant to the point I am trying to make. > > > > Keith Drage > > > > > > > --------------------------------------------------------------- > > > Keith Drage (keith.drage@siemenscomms.co.uk) > > > Siemens Communications Limited, > > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > > --------------------------------------------------------------- > > > Internet communications are not secure and therefore Siemens > > > Communications Limited does not accept legal responsibility for the > > > contents of this message. Any views or opinions presented are solely > > > those of the author and do not necessarily represent those > > of Siemens > > > Communications Limited unless otherwise specifically stated. > > > > > > 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 IP Phone Media Gateway > > > Application Profile > > > Author(s) : R. Bell, P. Blatherwick, P. Holland > > > Filename : draft-ietf-megaco-ipphone-02.txt > > > Pages : 13 > > > Date : 01-Mar-00 > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-megaco-ipphone-02.txt > > > > > > > > > > --------------------------------------------------------------- > > > Keith Drage (keith.drage@siemenscomms.co.uk) > > > Siemens Communications Limited, > > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > > --------------------------------------------------------------- > > > Internet communications are not secure and therefore Siemens > > > Communications Limited does not accept legal responsibility for the > > > contents of this message. Any views or opinions presented > > are solely those > > > of the author and do not necessarily represent those of Siemens > > > Communications Limited unless otherwise specifically stated. > > > > > > > > Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. -------------------------------------------------- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Mar 6 00:31:02 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17188 for ; Mon, 6 Mar 2000 00:31:01 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4BBC9E00@standards.nortelnetworks.com>; Mon, 6 Mar 2000 0:24:12 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 74119 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 00:22:28 -0500 Received: from tapti.hss.hns.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.82247E50@standards.nortelnetworks.com>; Mon, 6 Mar 2000 0:18:33 -0500 Received: from sandesh.hss.hns.com (sandesh.hss.hns.com [139.85.242.35]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id LAA07590; Mon, 6 Mar 2000 11:15:56 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525689A.001C7122 ; Mon, 6 Mar 2000 10:40:39 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525689A.001C66BB.00@sandesh.hss.hns.com> Date: Mon, 6 Mar 2000 10:42:28 +0530 Reply-To: samittal@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sachin Mittal Subject: Re: Questions About MEGACO/H.248 Version 16 X-To: Xiuping Qiu To: MEGACO@STANDARDS.NORTELNETWORKS.COM See Comments below. Xiuping Qiu on 02/29/2000 03:16:31 PM Please respond to Xiuping Qiu To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Sachin Mittal/HSS) Subject: Questions About MEGACO/H.248 Version 16 Hi,All I meet some questions when reading MEGACO/H.248 Version 16. 1. In Appendix A Step 23: " The MGC now sets up both MG1 and MG2 to be ready to detect the next off-hook event. See step 1. Note that this could be the default state of a termination in the null context, and if this were the case, no message need be sent from the MGC to the MG. Once a termination returns to the null context, it goes back to the default termination values for that termination. " I wonder how to implement the default state, e.g. request MG to detect the offhook event. And even if this were the case,I suppose messages also need be sent from the MGC to the MG to ask MG to detect offhook event because the RequestID now is different from the previous one. [SM] The default state is modified in NULL Context in step 3. I don't understand the confusion, The RequestID used in Notify will be the same as that used in Modify in NULL. So the Notify everytime will be of the form as shown in step 6. (request ID = 2222) No change in RequestID means no new message. 2. In 7.1.6 Stream Descriptor " StreamIDs are of local significance between MGC and MG and they are assigned by the MGC. Within a context, StreamID is a means by which to indicate which media flows are interconnected: streams with the same StreamID are connected " I am wondering whether StreamID will conflict with Topology. Let's suppose there are 2 Terminations ( T1 and T2) in a context . There is one stream on the 2 Terminations each but the StreamIDs are different. So the media flows are not interconnected. But if the Topology Descriptor of the Context is Bothway?, What will happen? [SM] They are not conflicting. Topology is the rule, and Streams are entities on which the rules work. If the rule doesn't apply no problem it may apply on new Streams. It may happen that more streams will get added to the two terminations and then the topology rule will apply. This is true also for the "mode" parameter of the streams that are candidates for inter-connection. Say two Streams with same StreamID are to be connected based on topology, but their "modes" are send-only then even though Streams are connected nothing is actually going "out of Context" on both Streams. There is another twist to this. Since Topology descriptor is optional to implement and is not implemented by a vendor then the mode parameter can be used to govern the connection direction. [But no topology means both-way connection] 3 In 6.2.5 Root Termination " Root thus may have properties and events (signals and statistics are not appropriate for root). " ? It is rather easy to imagine events of normal Terminations. But I cannot think of a case of using events for Root. Can you give an example ? And what events may a Root have ? [SM] Till now no event is defined in Base Root Package. but in new packages there can be events. Like Network interface going down or coming up if only one is there in each virtual MG. [This is different from the idea of making NIC as a termination which was floating sometime back in the mailing list] 4 In 7.1.1 Specifying Parameters " Unspecified mandatory parameters (i.e. mandatory parameters not specified in a descriptor) result in the command responder retaining the previous value for that parameter. Unspecified optional parameters result in the command responder using the default value of the parameter. Whenever a parameter is underspecified or overspecified, the descriptor containing the value chosen by the responder is included as output from the command. " Queston: It seems that "optional" ? here is not the same as that in Annex A defined in ASN.1. Will you expain them in detail? And what's the difference between "Unspecified Optional" ? and "Optional" . ?.And how to identify a unspecified parameter as mandatory or optional? [SM] Parameters are defined optional or mandatory by the text and in package definitions. Unspecifed Optional = An optional parameter whose value in a particular use is not provided. Optional = A parameter that is defined to be optional. These two terms seem to confuse if you see only the MGC perspective (optional or unspecified optional means the same thing as parameter value not specified) But in terms of MG an optional parameter has a default value and unspecifed case of optional parameter specify this value. When a Termination is Subtracted from a Context, the Topology should be changed, but how? There is no description in the protocol . Thanks, Xiuping Qiu _______________________________________________ Xiuping Qiu Huawei Technologies Co., Ltd. Mail to: qiuxiuping@sz.huawei.com.cn Tel : +86 755 654 4482 Visit : http://www.huawei.com.cn _______________________________________________ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Mar 6 04:40:55 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01331 for ; Mon, 6 Mar 2000 04:40:55 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8EE81F60@standards.nortelnetworks.com>; Mon, 6 Mar 2000 4:36:37 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 74432 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 04:34:45 -0500 Received: from smtp2.cluster.oleane.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4C264760@standards.nortelnetworks.com>; Mon, 6 Mar 2000 4:34:45 -0500 Received: from oleane (dyn-1-1-215.Vin.dialup.oleane.fr [195.25.4.215]) by smtp2.cluster.oleane.net with SMTP id KAA76974; Mon, 6 Mar 2000 10:38:08 +0100 (CET) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DE_01BF8757.73594D00" 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: <00e101bf874f$1e26f920$0401a8c0@oleane.com> Date: Mon, 6 Mar 2000 10:33:45 +0100 Reply-To: Peter Lewis Sender: "Media Gateway Control (megaco)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Peter Lewis Subject: SIP 2000 International Conference To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_00DE_01BF8757.73594D00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Unknown and even rejected by many vendors and operators only a few = months ago, SIP is on the brink of making a definitive name for itself.=20 Visit the SIP 2000 International Conference programme: http://www.upperside.fr/basip.htm ------=_NextPart_000_00DE_01BF8757.73594D00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Unknown and even rejected by many vendors and operators only a few = months=20 ago, SIP is on the brink of making a definitive name for itself.
Visit the SIP 2000 International Conference programme:
http://www.upperside.fr/basip.= htm
 
------=_NextPart_000_00DE_01BF8757.73594D00-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Mar 6 05:02:09 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01541 for ; Mon, 6 Mar 2000 05:02:09 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.686E1670@standards.nortelnetworks.com>; Mon, 6 Mar 2000 4:57:01 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 74665 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 04:56:07 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.485FC220@standards.nortelnetworks.com>; Mon, 6 Mar 2000 4:56:07 -0500 Received: from chsharp-tecra (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id BAA06734; Mon, 6 Mar 2000 01:59:47 -0800 (PST) X-Sender: chsharp@localhost.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.2.2.20000306185501.00ac2c90@localhost.cisco.com> Date: Mon, 6 Mar 2000 18:58:57 -0800 Reply-To: Chip Sharp Sender: "Media Gateway Control (megaco)" From: Chip Sharp Subject: Re: A small event handling ambiguity X-To: Steven Magnell To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <3.0.3.32.20000302115939.0575424c@exchange1nj.dialogic.com> The first line of the new text states: "The MG shall send a Notify command to the MGC when it detects an event in the Events Descriptor." Thus, if EventBufferControl = OFF, the above sentence applies to the current EventsDescriptor. The MG continues processing events according to the current EventsDescriptor until some other action happens that affects this (e.g., receipt of a new EventsDescriptor, changing the status of the EventBufferControl parameter, etc.). It is only if EventBufferControl=LockStep does the MG stop processing according to the current EventsDescriptor after the above action. At 11:59 AM 3/2/00 -0500, Steven Magnell wrote: >Maybe I was just too tired at the time we last discussed event handling, >but there seems to be a small ambiguity in the current description of event >handling (section 7.1.9) > >If the current state of event handling is where the MG is in LockStep mode, >processing events from the event buffer, event buffer control can be set to >off independent from loading of a new events descriptor. > >If this happens, all events in the buffer are discarded. The description of >handling events when in LockStep mode are all with respect to processing >events when a new descriptor has been loaded. > >For example, Case 2: "If EventBufferControl equals Off and the MG receives >a new EventsDescriptor, it processes new events with the new >EventsDescriptor". > >The ambiguity, at least in my mind, is what happens if no new events >descriptor has been loaded since the last event was detected and notified. > >Does the MG, once event buffer control has been set to off, process events >according to the last loaded events descriptor, even if it was deactivated >since it had detected an event while in LockStep mode, or is there now no >active events descriptor and a new one must be loaded before any event >processing can happen? > >Comments, Answers? > >Thanks, >steve magnell Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. -------------------------------------------------- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Mar 6 05:58:18 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01879 for ; Mon, 6 Mar 2000 05:58:18 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.64865B50@standards.nortelnetworks.com>; Mon, 6 Mar 2000 5:54:10 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 74774 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 05:52:57 -0500 Received: from fw-star02.starlinecommunications.fr (194.79.151.154) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D311AEA0@standards.nortelnetworks.com>; Mon, 6 Mar 2000 5:42:56 -0500 Received: from starlinecommunications.fr ([10.1.1.68]) by fw-star02.starlinecommunications.fr (Netscape Messaging Server 3.62) with ESMTP id 619 for ; Mon, 6 Mar 2000 11:39:46 +0100 X-Mailer: Mozilla 4.7 [fr] (WinNT; I) X-Accept-Language: fr MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------3BECE1647E6A3363ACE0C42E" Message-ID: <38C38C23.EF68F69E@starlinecommunications.fr> Date: Mon, 6 Mar 2000 11:44:51 +0100 Reply-To: Hakime Kechouri Sender: "Media Gateway Control (megaco)" From: Hakime Kechouri Organization: Starline Communications Subject: the Internet-Draft 'Media Gateway Control' To: MEGACO@STANDARDS.NORTELNETWORKS.COM Il s'agit d'un message multivolet au format MIME. --------------3BECE1647E6A3363ACE0C42E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Sirs Could you please send me the : Internet-Draft 'Media Gateway Control Protocol Architecture and Requirements' as an Informational RFC. This document is the product of the Media Gateway Control Working Group. The IESG contact persons are Scott Bradner and Vern Paxson --------------3BECE1647E6A3363ACE0C42E Content-Type: text/x-vcard; charset=us-ascii; name="hkechouri.vcf" Content-Description: Carte pour Hakime Content-Disposition: attachment; filename="hkechouri.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Kechouri;Hakime tel;fax:+33 1 41 19 11 66 tel;work:+33 1 41 19 11 26 x-mozilla-html:FALSE url:http://www.starlinecommunications.fr org:Starline Communications;92700 version:2.1 email;internet:hkechouri@starlinecommunications.fr adr;quoted-printable:;;Les Corvettes=0D=0A142-176 Av. de Stalingrad=0D=0A ;Colombes;;92700;France fn:Hakime Kechouri end:vcard --------------3BECE1647E6A3363ACE0C42E-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Mar 6 06:24:34 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02053 for ; Mon, 6 Mar 2000 06:24:29 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.08E3F6F0@standards.nortelnetworks.com>; Mon, 6 Mar 2000 6:20:14 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 74834 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 06:18:40 -0500 Received: from relay.mail.pipex.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D0893CC0@standards.nortelnetworks.com>; Mon, 6 Mar 2000 6:18:40 -0500 Received: (qmail 10794 invoked from network); 6 Mar 2000 11:22:18 -0000 Received: from gatekeeper.sgcs.co.uk (HELO bevx03.gpt.co.uk) (194.129.217.113) by iprelay.mail.pipex.net with SMTP; 6 Mar 2000 11:22:18 -0000 Received: from CONVERSION-DAEMON by siemenscomms.co.uk (PMDF V5.1-12 #D3115) id <01JMPL8HBGF490NDMK@siemenscomms.co.uk>; Mon, 6 Mar 2000 11:15:14 GMT Received: from beex01.sgcs.co.uk ([19.0.53.101]) by siemenscomms.co.uk (PMDF V5.1-12 #D3115) with ESMTP id <01JMPKSL9DGW90NMNP@siemenscomms.co.uk>; Mon, 06 Mar 2000 10:57:27 +0000 (GMT) Received: by beex01.sgcs.co.uk with Internet Mail Service (5.5.2448.0) id ; Mon, 06 Mar 2000 11:01:12 +0000 Content-return: allowed MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Message-ID: <5AC7D3F55147D311AA1700A0C99583ED2C368C@beex03.sgcs.co.uk> Date: Mon, 6 Mar 2000 11:01:03 +0000 Reply-To: "Drage, Keith" Sender: "Media Gateway Control (megaco)" Comments: *********************************************** Comments: * Our domain is now siemenscomms.co.uk * Comments: * Please update your address book accordingly * Comments: *********************************************** From: "Drage, Keith" Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt X-To: Peter Blatherwick To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7BIT The section of text encoding versus binary encoding is an option within MG. At the implementation level, the MG can implement one, or the other, or both. My issue is whether IETF should provide a selection of this option within a profile, given its agreements with ITU-T. I would be considerably happier with allowing this if the main MEGACO/H.248 document said MUST (or in ITU-T SHALL) instead of SHOULD, for the related MGC requirement. If the IETF puts a selection of this option at the MG in the profile, then the IETF is effectively saying for the MGC: "the MGC MUST support text encoding and the MGC SHOULD support binary encoding". My understanding of the discussion of the encoding issue when previously discussed in both ITU-T and IETF was that the status was unresolvable in the standards world and would be left to market forces to make the decision. I also see no need why a MG profile should constrain the option for this particular application. If one encoding is so much more complex that the other (as some people on the list appear to think), and so much more hungry of hardware resources such as memory, then this one choice will prove to be considerably more expensive that the other and the market will decide by not buying the expensive one. In general for profiles, I have no problem with IETF creating a valid profile for a specific application. I think including the encoding issue within an IETF published profile is the tricky problem. In the draft, there are other statements, where the protocol is subsetted, which are not valid for a profile. I would therefore repeat my request that MEGACO should clearly identify in its discussions what are valid options that can be profiled, as well as the issue of who is allowed to create profiles. These selectable options must be clearly based on the text that exists in the main MEGACO/H.248 document. Keith Drage --------------------------------------------------------------- Keith Drage (keith.drage@siemenscomms.co.uk) Siemens Communications Limited, Technology Drive, Beeston, Nottingham NG9 1LA, UK Tel: +44 115 943 4991 Fax: +44 115 943 4992 --------------------------------------------------------------- Internet communications are not secure and therefore Siemens Communications Limited does not accept legal responsibility for the contents of this message. Any views or opinions presented are solely those of the author and do not necessarily represent those of Siemens Communications Limited unless otherwise specifically stated. -----Original Message----- From: Peter Blatherwick [mailto:blather@NORTELNETWORKS.COM] Sent: Saturday, March 04, 2000 12:39 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt Keith, Mike, others, It is very definitely NOT our intent to create friction between ITU and IETF in our extremely admirable co-operative effort on the H.248/Megaco protocol. It is also not our intent to set any constraints or precedents on how other applications of the protocol work, whether these applications are defined in IETF, ITU or elsewhere. This is in no way an attempt to side-step agreed process. Our intent is to define a particular application of the protocol, primarily targeted at creating cost-optimized embedded devices. In this specific case, as with other very small scale applications, a choice on both encoding and transport absolutely must be made, to reduce memory footprint. (We would like to see other reductions as well, but let's talk about that separately.) We chose text encoding since it seems to us more easily and compactly implementable for this particular application. The transport selection (ALF) was decided for similar pragmatic reasons. This does not necessarily reflect on any other application. It may well be that we are wrong on these choices, but a decision has to be made to move forward. As Brian has already noted, these are both options in the protocol at the MG side. Note also that the profile does not restrict use of binary encoding as well as text, just that the text encoding must be implemented. The same logic applies to transport. The point that we must decide where to settle definition of this and other applications/profiles is well taken, and I agree its at the core of the debate. However, I personally believe it is important to settle some specific applications of the protocol soon, leading towards interoperability testing and validation, which are natural parts of the IETF side of the joint process. Then again, I'm no process guru... I hope that helps, and apologize for not making it more clear up front. Peter Blatherwick -----Original Message----- From: Mike Buckley [SMTP:mikebuckley@ATTMAIL.COM] Sent: Friday, March 03, 2000 8:35 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt I agree wholeheartedly with Keith Drage's comment: >Surely it also dishonours the agreement between the ITU-T and IETF groups, >as they participated in agreeing the words that go in H.248/MEGACO, but do >not apparently participate in discussing the profile that then gets >subsequently published by IETF. This attempt to sidestep the agreement with the ITU can only create bad faith between the two organizations. The Megaco wording was arrived at after lengthy discussions and compromise on both sides. The consequences of unilaterally trying to pursue one line will ony result in the ITU going off in an incompatible direction. Is this what the market wants - an IETF package specifying text encoding and an ITU Annex specifying binary? This is not the way to resolve the text v. binary issue and it is not the way to built good relations between the two Standards bodies. Agreements should be honoured by both sides in the spirit as well as the letter. Mike Buckley ____________________ Begin Original Message ___________________________ Date: Fri Mar 3 08:05:04 -0500 2000 From: internet!FORE.COM!brosen (Rosen, Brian) Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt To: internet!STANDARDS.NORTELNETWORKS.COM!MEGACO Content-Type: Generic-Text Content-Length: 5599 There are two threads in this message I wish to comment on. 1. The issue of text encoding. Text/Binary Encoding is defined in the protocol as optional. A profile could make a choice. It is acceptable to me that such a choice be made in this profile. 2. Subsets of the protocol. I have been vociferous in positing that profiles cannot subset the protocol. If the protocol defines something as optional, then the profile can declare what options shall be implemented. Where there is not an option, profiles should not make something optional. If it does, it's a new protocol. Call it that, and we can decide if we want to standardize a new protocol. I personally do not believe that an IPPhone needs to subset the Megaco protocol. Brian > -----Original Message----- > From: Drage, Keith [ mailto:Keith.Drage@SIEMENSCOMMS.CO.UK ] > Sent: Friday, March 03, 2000 4:43 AM > To: MEGACO@standards.nortelnetworks.com > Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt > > > I note that this proposed profile contains the text: > > "Megaco IP Phone MGs MUST support text encoding of the protocol, as > specified in the Megaco/H.248 Protocol document [3]." > > While I DO NOT want to reopen the encoding debate, it seems > inappropriate to > me that MEGACO should create a profile that further restricts it own > product. I understood the summary of the text versus binary > debate was that > the decision on encoding would be made by market forces, and was NOT > application dependent. If there is an application dependency, then > guidelines to that dependency should surely be given in the > main MEGACO > protocol document. > > Surely it also dishonours the agreement between the ITU-T and > IETF groups, > as they participated in agreeing the words that go in > H.248/MEGACO, but do > not apparently participate in discussing the profile that then gets > subsequently published by IETF. > > I would have therefore thought that if TIA wish to restrict > the encoding > choice, then it is up to TIA to publish the profile, rather > than the IETF. > > Looking further, I notice that the document also defines > constraints on the > usage of Events, etc. Reading the main MEGACO protocol document, I > understand that variations on termination characteristics should be > implemented by specification of a package. Should these restrictions > therefore be defined by a new package? > > I guess we need some general discussion on what is possible > in profiles, as > opposed to packages, and whether MEGACO should define > profiles that are > still nominally called MEGACO, but do not exhibit all the > requirements of > the main document. Rephrasing in a slightly different way, > which are the > options, and which of these options that are selected based > on the type of > application (and therefore suitable for specification in > profiles for a > particular application), and which are implementation options > (and selected > because an implementor wishes to make his product different > and presumably > better/cheaper/fit the available memory than another market entrant). > > Rephrasing the question a different way, with the > restrictions imposed by > this "profile", can the result still be MEGACO/H.248, or has it really > invented a new protocol? > > Let me stress again, I do not want to see any responses that > it is done this > way because text is better than binary, or more efficient. > The answer to > that is irrelevant to the point I am trying to make. > > Keith Drage > > > > --------------------------------------------------------------- > > Keith Drage (keith.drage@siemenscomms.co.uk) > > Siemens Communications Limited, > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > --------------------------------------------------------------- > > Internet communications are not secure and therefore Siemens > > Communications Limited does not accept legal responsibility for the > > contents of this message. Any views or opinions presented are solely > > those of the author and do not necessarily represent those > of Siemens > > Communications Limited unless otherwise specifically stated. > > > > 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 IP Phone Media Gateway > > Application Profile > > Author(s) : R. Bell, P. Blatherwick, P. Holland > > Filename : draft-ietf-megaco-ipphone-02.txt > > Pages : 13 > > Date : 01-Mar-00 > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-megaco-ipphone-02.txt > > > > > > --------------------------------------------------------------- > > Keith Drage (keith.drage@siemenscomms.co.uk) > > Siemens Communications Limited, > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > --------------------------------------------------------------- > > Internet communications are not secure and therefore Siemens > > Communications Limited does not accept legal responsibility for the > > contents of this message. Any views or opinions presented > are solely those > > of the author and do not necessarily represent those of Siemens > > Communications Limited unless otherwise specifically stated. > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Mar 6 06:33:25 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02162 for ; Mon, 6 Mar 2000 06:33:25 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4CF1BA70@standards.nortelnetworks.com>; Mon, 6 Mar 2000 6:29:18 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 74833 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 06:28:06 -0500 Received: from s1.smtp.oleane.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BC15A440@standards.nortelnetworks.com>; Mon, 6 Mar 2000 6:18:05 -0500 Received: from peterpan.oleane.net (peterpan.oleane.net [194.2.28.11]) by s1.smtp.oleane.net with ESMTP id MAA09965 for ; Mon, 6 Mar 2000 12:10:20 +0100 Received: from nettest.nettest.fr (mailhost.nettest.fr [195.25.217.89]) by peterpan.oleane.net with ESMTP id MAA13376 for ; Mon, 6 Mar 2000 12:10:15 +0100 Received: from nettest.fr (192.168.0.11) by nettest.nettest.fr (Worldmail 1.3.167) for megaco@standards.nortelnetworks.com; 6 Mar 2000 12:03:14 +0100 X-Mailer: Mozilla 4.6 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------A668D1A06D1951522EA3D902" Message-ID: <38C391BD.8BC8D6B2@nettest.fr> Date: Mon, 6 Mar 2000 12:08:46 +0100 Reply-To: Guillaume TRICHARD Sender: "Media Gateway Control (megaco)" From: Guillaume TRICHARD Organization: GN Nettest France Subject: MEGACO versus MGCP To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------A668D1A06D1951522EA3D902 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I am realizing a study which can be titled "MEGACO versus MGCP". So I'm looking for information about the advantages and disadvantages of both. As a new member on this mailing list, I would very pleased if you can e-mail me some information. Thx Guillaume GN Nettest France --------------A668D1A06D1951522EA3D902 Content-Type: text/x-vcard; charset=us-ascii; name="g.trichard.vcf" Content-Description: Card for Guillaume TRICHARD Content-Disposition: attachment; filename="g.trichard.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:TRICHARD;Guillaume tel;fax:+33 1 69 41 80 95 tel;work:+33 1 69 41 26 66 x-mozilla-html:FALSE url:www.gnnettest.com org:GN Nettest France adr:;;4, rue René Razel;ORSAY CEDEX;;91892;FRANCE version:2.1 email;internet:g.trichard@nettest.fr title:Marketing Assistant fn:Guillaume TRICHARD end:vcard --------------A668D1A06D1951522EA3D902-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Mar 6 07:32:52 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03290 for ; Mon, 6 Mar 2000 07:32:52 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9158BD50@standards.nortelnetworks.com>; Mon, 6 Mar 2000 7:28:29 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 75002 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 07:28:00 -0500 Received: from relay.mail.pipex.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.806A53F0@standards.nortelnetworks.com>; Mon, 6 Mar 2000 7:28:00 -0500 Received: (qmail 19350 invoked from network); 6 Mar 2000 12:31:43 -0000 Received: from gatekeeper.sgcs.co.uk (HELO bevx03.gpt.co.uk) (194.129.217.113) by iprelay.mail.pipex.net with SMTP; 6 Mar 2000 12:31:43 -0000 Received: from CONVERSION-DAEMON by siemenscomms.co.uk (PMDF V5.1-12 #D3115) id <01JMPL8HBGF490NDMK@siemenscomms.co.uk>; Mon, 6 Mar 2000 12:26:42 GMT Received: from beex01.sgcs.co.uk ([19.0.53.101]) by siemenscomms.co.uk (PMDF V5.1-12 #D3115) with ESMTP id <01JMPL5NNYJ490NMR8@siemenscomms.co.uk>; Mon, 06 Mar 2000 11:07:58 +0000 (GMT) Received: by beex01.sgcs.co.uk with Internet Mail Service (5.5.2448.0) id ; Mon, 06 Mar 2000 11:11:49 +0000 Content-return: allowed MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Message-ID: <5AC7D3F55147D311AA1700A0C99583ED2C368D@beex03.sgcs.co.uk> Date: Mon, 6 Mar 2000 11:11:45 +0000 Reply-To: "Drage, Keith" Sender: "Media Gateway Control (megaco)" Comments: *********************************************** Comments: * Our domain is now siemenscomms.co.uk * Comments: * Please update your address book accordingly * Comments: *********************************************** From: "Drage, Keith" Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt X-To: Chip Sharp To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7BIT Chip Sharp wrote: > > I assume that I can depend on everyone to stand up and defend > text encoding > if Study Group 11 mandates binary encoding for BICC's use of > H.248 in the > interest of harmony? > ;-) > I understood (from standing on the sidelines) that BICC's usage would be defined by appropriate package rather than a profile. It is not appropriate for package documentation to specify an encoding mechanism. I admit that the formal discussion of this has not yet occurred and will not occur until the next ITU-T BICC discussion at the earliest. Given my superficial understanding of various network operator positions, I suspect it would also be difficult to come to a consensus decision on selecting one option or the other, and trying to make such a decision will mean missing the delivery dates. Keith Drage > --------------------------------------------------------------- > Keith Drage (keith.drage@siemenscomms.co.uk) > Siemens Communications Limited, > Technology Drive, Beeston, Nottingham NG9 1LA, UK > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > --------------------------------------------------------------- > Internet communications are not secure and therefore Siemens > Communications Limited does not accept legal responsibility for the > contents of this message. Any views or opinions presented are solely > those of the author and do not necessarily represent those of Siemens > Communications Limited unless otherwise specifically stated. > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Mar 6 12:27:25 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15997 for ; Mon, 6 Mar 2000 12:27:24 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B7147B50@standards.nortelnetworks.com>; Mon, 6 Mar 2000 12:23:01 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 76184 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 12:21:06 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7224C6D0@standards.nortelnetworks.com>; Mon, 6 Mar 2000 12:21:06 -0500 Received: from zmers013 by smtprch1.nortel.com; Mon, 6 Mar 2000 11:23:09 -0600 Received: from zrchb213.us.nortel.com (actually zrchb213) by zmers013; Mon, 6 Mar 2000 12:22:42 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 6 Mar 2000 11:22:40 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8790.92D3D5E0" Message-ID: Date: Mon, 6 Mar 2000 11:22:39 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Questions About MEGACO/H.248 Version 16 X-To: Xiuping Qiu 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_01BF8790.92D3D5E0 Content-Type: text/plain; charset="iso-8859-1" Responses below. I started this message quite a while ago, but it got buried before I got around to sending it. > -----Original Message----- > From: Xiuping Qiu [SMTP:qiuxiuping@SZ.HUAWEI.COM.CN] > Sent: Tuesday, February 29, 2000 4:47 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Questions About MEGACO/H.248 Version 16 > > Hi,All > > I meet some questions when reading MEGACO/H.248 Version 16. > > 1. In Appendix A > > Step 23: " The MGC now sets up both MG1 and MG2 to be ready to detect the > next off-hook event. See step 1. Note that this could be the default state > of a termination in the null context, and if this were the case, no > message need be sent from the MGC to the MG. Once a termination returns to > the null context, it goes back to the default termination values for that > termination. " > > I wonder how to implement the default state, e.g. request MG to detect > the offhook event. And even if this were the case,I suppose messages also > need be sent from the MGC to the MG to ask MG to detect offhook event > because the RequestID now is different from the previous one. [[TomT]] One of the changes made in Geneva was to rule out the idea that a termination remembers the settings it was last given while in the null context. The default settings are therefore either those defined in the Megaco/H.248 specs. (and there are actually very few of those) or those established through provisioning. The passage you quote was written before this change was made. In any event, I think you are right in practice -- it is desirable for the MGC to reestablish the termination's idle state when it moves it to the null context. A typical implementation would be to have, within the same transaction, a Subtract followed by a Modify which sets up a timed watch for on-hook (assuming that had not already happened), with embedded event descriptors as follows: -- on-hook detected: watch for off-hook -- timer expired: notify the MGC and apply receiver off hook warning tone. This suggests to me that one thing we need to add in an extension of the Generic package is an explicit timer event. I'd be interested in others' comments on this one. > 2. In 7.1.6 Stream Descriptor > > " StreamIDs are of local significance between MGC and MG and they are > assigned by the MGC. Within a context, StreamID is a means by which to > indicate which media flows are interconnected: streams with the same > StreamID are connected " > > I am wondering whether StreamID will conflict with Topology. > > Let's suppose there are 2 Terminations ( T1 and T2) in a context . There > is one stream on the 2 Terminations each but the StreamIDs are different. > So the media flows are not interconnected. But if the Topology Descriptor > of the Context is > Bothway", What will happen? [[TomT]] Topology is sort of a global property -- it defines inter-termination connectivity regardless of the details of which streams are flowing. Streams add a level of detail within that framework: A may talk to B in general, but B doesn't happen to support the video that A is prepared to provide. One could conceive of making topology stream-specific, but I don't think there's a real requirement for that level of control. > 3 In 6.2.5 Root Termination > > " Root thus may have properties and events (signals and statistics are not > appropriate for root). " > " > It is rather easy to imagine events of normal Terminations. But I > cannot think of a case of using events for Root. Can you give an > example ? And what events may a Root have ? [[TomT]] The sort of events I imagine are related to resource management (e.g. transition to/from an overload state). We have not yet defined any packages implementing ROOT events. > 4 In 7.1.1 Specifying Parameters > > " Unspecified mandatory parameters (i.e. mandatory parameters not > specified in a descriptor) result in the command responder retaining the > previous value for that parameter. Unspecified optional parameters result > in the command responder using the default value of the parameter. > Whenever a parameter is underspecified or overspecified, the descriptor > containing the value chosen by the responder is included as output from > the command. " > > Queston: > It seems that "optional" " here is not the same as that in Annex A defined > in ASN.1. Will you expain them in detail? And what's the difference > between "Unspecified Optional" " and "Optional" . ".And how to identify > a unspecified parameter as mandatory or optional? [[TomT]] Personally I think this text is going to need a lot of detailed interpretation. Let's start by agreeing (I hope) that this statement applies to the contents of descriptors, not to whether or not the descriptors themselves are present. Going on from there, however, it's pretty tough to sort out what is optional and what isn't. I have a feeling we will need a supplementary guide to list the parameters which take on "previous value" versus those which take on "default value". I would tend to play it safe and specify everything. An unspecified parameter, whether mandatory or optional, is one which is simply not present within a particular instance of the descriptor. This contrasts with UNDERspecification through the use of ranges, alternatives, or the CHOOSE wildcard. > When a Termination is Subtracted from a Context, the Topology should be > changed, but how? There is no description in the protocol . > [[TomT]] Isn't that straightforward? Topology may be viewed as a series of binary relationships -- between pairs of terminations. When a termination is subtracted, all relationships in which it appears are deleted. > Thanks, > Xiuping Qiu > _______________________________________________ > > Xiuping Qiu > Huawei Technologies Co., Ltd. > Mail to: qiuxiuping@sz.huawei.com.cn > Tel : +86 755 654 4482 > Visit : http://www.huawei.com.cn > _______________________________________________ ------_=_NextPart_001_01BF8790.92D3D5E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Questions About MEGACO/H.248 Version 16

Responses = below.  I started this message quite a while ago, but it got = buried before I got around to sending it.

    -----Original Message-----
    From:   Xiuping Qiu = [SMTP:qiuxiuping@SZ.HUAWEI.COM.CN]
    Sent:   Tuesday, February 29, 2000 4:47 AM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Questions About MEGACO/H.248 Version = 16

    Hi,All

    I meet some questions when reading = MEGACO/H.248 Version 16.

    1. In Appendix A

    Step 23: "  The MGC now sets = up both MG1 and MG2 to be ready to detect the next off-hook event. See = step 1. Note that this could be the default state of a termination in = the null context, and if this were the case, no message need be sent = from the MGC to the MG. Once a termination returns to the null context, = it goes back to the default termination values for that = termination.  "

    I wonder how to implement the  = default state, e.g. request MG to detect the offhook event. And even if = this were the case,I suppose messages also need be sent from the MGC to = the MG to ask MG to detect offhook event because the RequestID now is = different from the previous one.

    [[TomT]] 
    One of the changes = made in Geneva was to rule out the idea that a termination remembers = the settings it was last given while in the null context.  The = default settings are therefore either those defined in the Megaco/H.248 = specs. (and there are actually very few of those) or those established = through provisioning.  The passage you quote was written before = this change was made.  In any event, I think you are right in = practice -- it is desirable for the MGC to reestablish the = termination's idle state when it moves it to the null context.  A = typical implementation would be to have, within the same transaction, a = Subtract followed by a Modify which sets up a timed watch for on-hook = (assuming that had not already happened), with embedded event = descriptors as follows:

     -- on-hook = detected: watch for off-hook
     -- timer = expired: notify the MGC and apply receiver off hook warning = tone.

    This suggests to me = that one thing we need to add in an extension of the Generic package is = an explicit timer event.  I'd be interested in others' comments on = this one.

    2. In 7.1.6 Stream Descriptor

    " StreamIDs are of local = significance between MGC and MG and they are assigned by the MGC.  = Within a context, StreamID is a means by which to indicate which media = flows are interconnected:  streams with the same StreamID are = connected  "

    I am wondering whether StreamID will = conflict  with Topology.

    Let's  suppose there are 2 = Terminations ( T1 and T2)  in a context . There is one stream on = the 2 Terminations each but the StreamIDs are different. So  the = media flows are not interconnected. But if the Topology Descriptor of = the Context is

    Bothway", What will happen?
    [[TomT]] 
    Topology is sort of = a global property -- it defines inter-termination connectivity = regardless of the details of which streams are flowing.  Streams = add a level of detail within that framework: A may talk to B in = general, but B doesn't happen to support the video that A is prepared = to provide.  One could conceive of making topology = stream-specific, but I don't think there's a real requirement for that = level of control.

    3  In  6.2.5  Root = Termination

    " Root thus may have properties = and events (signals and statistics are not appropriate for root).  = "
    "=02
    It is rather easy  to = imagine  events of   normal Terminations.  But I = cannot think of  a case of using events for Root.  Can = you  give an example ?  And what events may a Root have = ?

    [[TomT]] 
    The sort of events = I imagine are related to resource management (e.g. transition to/from = an overload state).  We have not yet defined any packages = implementing ROOT events.

    4  In  7.1.1  = Specifying Parameters

    "  Unspecified mandatory = parameters (i.e. mandatory parameters not specified in a descriptor) = result in the command responder retaining the previous value for that = parameter.  Unspecified optional parameters result in the command = responder using the default value of the = parameter.      Whenever a parameter is = underspecified or overspecified, the descriptor containing the value = chosen by the responder is included as output from the command.  = "

    Queston:
    It seems that "optional" " = here is not the same as that in Annex A defined in ASN.1.  Will = you   expain them in detail? And what's the difference = between "Unspecified Optional"  " and  = "Optional" . ".And how to identify a unspecified parameter as = mandatory or optional?

    [[TomT]] 
    Personally I think = this text is going to need a lot of detailed interpretation.  = Let's start by agreeing (I hope) that this statement applies to the = contents of descriptors, not to whether or not the descriptors = themselves are present.  Going on from there, however, it's pretty = tough to sort out what is optional and what isn't.  I have a = feeling we will need a supplementary guide to list the parameters which = take on "previous value" versus those which take on = "default value".  I would tend to play it safe and = specify everything.

    An unspecified = parameter, whether mandatory or optional, is one which is simply not = present within a particular instance of the descriptor.  This = contrasts with UNDERspecification through the use of ranges, = alternatives, or the CHOOSE wildcard.


    When a  Termination is Subtracted = from a  Context, the Topology  should be changed, but how? = There is no description in the protocol .

    [[TomT]]  Isn't that = straightforward?  Topology may be viewed as a series of binary = relationships -- between pairs of terminations.  When a = termination is subtracted, all relationships in which it appears are = deleted.

    Thanks,
    Xiuping Qiu
    _______________________________________________

    Xiuping Qiu
    Huawei Technologies Co., Ltd.
    Mail to:   = qiuxiuping@sz.huawei.com.cn
    Tel    :   = +86 755 654 4482
    Visit  :   = http://www.huawei.com.cn
    _______________________________________________

------_=_NextPart_001_01BF8790.92D3D5E0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Mar 6 15:46:41 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28084 for ; Mon, 6 Mar 2000 15:46:41 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8D670360@standards.nortelnetworks.com>; Mon, 6 Mar 2000 15:42:17 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 76372 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 15:41:03 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.612C61A0@standards.nortelnetworks.com>; Mon, 6 Mar 2000 15:41:03 -0500 Received: from zmers013 by smtprch1.nortel.com; Mon, 6 Mar 2000 14:40:41 -0600 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by zmers013; Mon, 6 Mar 2000 15:40:16 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 6 Mar 2000 15:40:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF87AC.2BC2B5EE" Message-ID: Date: Mon, 6 Mar 2000 15:40:11 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: ServiChangeReply definition question? X-To: marko.onikki@NOKIA.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_01BF87AC.2BC2B5EE Content-Type: text/plain Basically the point you are making is that the ServiceChangeReply could contain an empty serviceChangeResult, and this is inefficient compared with making serviceChangeResult optional. I note that the corresponding ABNF requires at least one parameter in serviceChangeReplyDescriptor. In fact, none of the serviceChangeReplyDescriptor parameters are meaningful when a non-ROOT termination is involved. I think we should therefore adopt your suggestion and simply make serviceChangeResult optional (with corresponding fixes to the ABNF). > -----Original Message----- > From: Marko Onikki [SMTP:marko.onikki@NOKIA.COM] > Sent: Thursday, March 02, 2000 8:34 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: ServiChangeReply definition question? > > Hi, to everyone! > > Could someone tell to me is in MEGACO/H.248 v.15 specification error in > ServiceChangeReply definition? > > ServiChangeReply is defined like this: > > ServiceChangeReply ::= SEQUENCE > > { > > terminationID TerminationIDList, > > serviceChangeResult ServiceChangeResult, -->> > ServiceChangeResult OPTIONAL > > ... > > } > > > -- For ServiceChangeResult, no parameters are mandatory. Hence the > > -- distinction between ServiceChangeParm and ServiceChangeResParm. > > > > My opinion is that ServiceChangeResult should be OPTIONAL part because > ServiChangeResult is divided to CHOICE structure > > ServiceChangeResult ::= CHOICE > > { > > errorDescriptor ErrorDescriptor, > > serviceChangeResParms ServiceChangeResParm > > } > > > ServiceChangeResParm ::= SEQUENCE > > { > > serviceChangeMgcId MId OPTIONAL, > > serviceChangeAddress ServiceChangeAddress OPTIONAL, > > serviceChangeVersion INTEGER(0..99) OPTIONAL, > > serviceChangeProfile ServiceChangeProfile OPTIONAL > > } > > > > > and if ServiceChangeResParm is choosed there migth not be any data at all > in > ServiceChangeResParm because ServiceChangeResParm consist only from > OPTIONAL > parts. > > Br, > > Marko Onikki > Nokia Networks > E-mail. marko.onikki@nokia.com ------_=_NextPart_001_01BF87AC.2BC2B5EE Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: ServiChangeReply definition question?

Basically the point = you are making is that the ServiceChangeReply could contain an empty = serviceChangeResult, and this is inefficient compared with making = serviceChangeResult optional.  I note that the corresponding ABNF = requires at least one parameter in = serviceChangeReplyDescriptor.

In fact, none of the = serviceChangeReplyDescriptor parameters are meaningful when a non-ROOT = termination is involved.  I think we should therefore adopt your = suggestion and simply make serviceChangeResult optional (with = corresponding fixes to the ABNF).

    -----Original Message-----
    From:   Marko Onikki = [SMTP:marko.onikki@NOKIA.COM]
    Sent:   Thursday, March 02, 2000 8:34 AM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = ServiChangeReply definition = question?

    Hi, to everyone!

    Could someone tell to me is in = MEGACO/H.248 v.15 specification error in
    ServiceChangeReply definition?

    ServiChangeReply is defined like = this:

    ServiceChangeReply ::=3D = SEQUENCE

    {

            = terminationID          = ;         = TerminationIDList,

            = serviceChangeResult         = ;    ServiceChangeResult,    = -->>
    ServiceChangeResult OPTIONAL

            ...

    }


    -- For ServiceChangeResult, no = parameters are mandatory.  Hence the

    -- distinction between = ServiceChangeParm and ServiceChangeResParm.



    My opinion is that ServiceChangeResult = should be OPTIONAL part because
    ServiChangeResult is divided to = CHOICE structure

    ServiceChangeResult ::=3D = CHOICE

    {

            = errorDescriptor         &nb= sp;       ErrorDescriptor,

            = serviceChangeResParms        &nb= sp;  ServiceChangeResParm

    }


    ServiceChangeResParm ::=3D = SEQUENCE

    {

            = serviceChangeMgcId      MId OPTIONAL,

          &nb= sp; serviceChangeAddress    ServiceChangeAddress = OPTIONAL,

            = serviceChangeVersion    INTEGER(0..99) OPTIONAL,

    serviceChangeProfile    = ServiceChangeProfile OPTIONAL

    }




    and if ServiceChangeResParm is choosed = there migth not be any data at all in
    ServiceChangeResParm because = ServiceChangeResParm consist only from OPTIONAL
    parts.

    Br,

    Marko Onikki
    Nokia Networks
    E-mail. marko.onikki@nokia.com

------_=_NextPart_001_01BF87AC.2BC2B5EE-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Mar 6 15:55:34 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29205 for ; Mon, 6 Mar 2000 15:55:32 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D0A7B2E0@standards.nortelnetworks.com>; Mon, 6 Mar 2000 15:51:20 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 76396 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 15:49:34 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.917BABD0@standards.nortelnetworks.com>; Mon, 6 Mar 2000 15:49:34 -0500 Received: from zmers013 by smtprch1.nortel.com; Mon, 6 Mar 2000 14:52:21 -0600 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by zmers013; Mon, 6 Mar 2000 15:51:59 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 6 Mar 2000 15:51:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF87AD.D0FD0CC0" Message-ID: Date: Mon, 6 Mar 2000 15:51:58 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: ServiChangeReply definition question? X-To: marko.onikki@NOKIA.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_01BF87AD.D0FD0CC0 Content-Type: text/plain Oops. Got confused in reading the ABNF. serviceChangeReplyDescriptor is optional in the ABNF already. We can do the same for the ASN.1, but it's not going to change the meaning of any messages. > -----Original Message----- > From: Taylor, Tom-PT [CAR:B904:EXCH] > Sent: Monday, March 06, 2000 3:40 PM > To: 'marko.onikki@NOKIA.COM'; MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: RE: ServiChangeReply definition question? > > Basically the point you are making is that the ServiceChangeReply could > contain an empty serviceChangeResult, and this is inefficient compared > with making serviceChangeResult optional. I note that the corresponding > ABNF requires at least one parameter in serviceChangeReplyDescriptor. > > In fact, none of the serviceChangeReplyDescriptor parameters are > meaningful when a non-ROOT termination is involved. I think we should > therefore adopt your suggestion and simply make serviceChangeResult > optional (with corresponding fixes to the ABNF). > > -----Original Message----- > From: Marko Onikki [SMTP:marko.onikki@NOKIA.COM] > Sent: Thursday, March 02, 2000 8:34 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: ServiChangeReply definition question? > > Hi, to everyone! > > Could someone tell to me is in MEGACO/H.248 v.15 specification error > in > ServiceChangeReply definition? > > ServiChangeReply is defined like this: > > ServiceChangeReply ::= SEQUENCE > > { > > terminationID TerminationIDList, > > serviceChangeResult ServiceChangeResult, -->> > ServiceChangeResult OPTIONAL > > ... > > } > > > -- For ServiceChangeResult, no parameters are mandatory. Hence the > > -- distinction between ServiceChangeParm and ServiceChangeResParm. > > > > My opinion is that ServiceChangeResult should be OPTIONAL part > because > ServiChangeResult is divided to CHOICE structure > > ServiceChangeResult ::= CHOICE > > { > > errorDescriptor ErrorDescriptor, > > serviceChangeResParms ServiceChangeResParm > > } > > > ServiceChangeResParm ::= SEQUENCE > > { > > serviceChangeMgcId MId OPTIONAL, > > serviceChangeAddress ServiceChangeAddress OPTIONAL, > > serviceChangeVersion INTEGER(0..99) OPTIONAL, > > serviceChangeProfile ServiceChangeProfile OPTIONAL > > } > > > > > and if ServiceChangeResParm is choosed there migth not be any data > at all in > ServiceChangeResParm because ServiceChangeResParm consist only from > OPTIONAL > parts. > > Br, > > Marko Onikki > Nokia Networks > E-mail. marko.onikki@nokia.com ------_=_NextPart_001_01BF87AD.D0FD0CC0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: ServiChangeReply definition question?

Oops.  Got = confused in reading the ABNF.  serviceChangeReplyDescriptor is = optional in the ABNF already.  We can do the same for the ASN.1, = but it's not going to change the meaning of any messages.

    -----Original Message-----
    From:   Taylor, Tom-PT [CAR:B904:EXCH]
    Sent:   Monday, March 06, 2000 3:40 PM
    To:     'marko.onikki@NOKIA.COM'; = MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = RE: ServiChangeReply definition = question?

    Basically the point = you are making is that the ServiceChangeReply could contain an empty = serviceChangeResult, and this is inefficient compared with making = serviceChangeResult optional.  I note that the corresponding ABNF = requires at least one parameter in = serviceChangeReplyDescriptor.

    In fact, none of the = serviceChangeReplyDescriptor parameters are meaningful when a non-ROOT = termination is involved.  I think we should therefore adopt your = suggestion and simply make serviceChangeResult optional (with = corresponding fixes to the ABNF).

      -----Original Message-----
      From:   Marko Onikki = [SMTP:marko.onikki@NOKIA.COM]
      Sent:   Thursday, March 02, 2000 8:34 AM
      To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
      Subject:       = ServiChangeReply definition = question?

      Hi, to everyone!

      Could someone tell to me is in = MEGACO/H.248 v.15 specification error in
      ServiceChangeReply definition?

      ServiChangeReply is defined like = this:

      ServiceChangeReply ::=3D = SEQUENCE

      {

              = terminationID          = ;         = TerminationIDList,

              = serviceChangeResult         = ;    ServiceChangeResult,    = -->>
      ServiceChangeResult OPTIONAL

              ...

      }


      -- For ServiceChangeResult, no = parameters are mandatory.  Hence the

      -- distinction between = ServiceChangeParm and ServiceChangeResParm.



      My opinion is that ServiceChangeResult = should be OPTIONAL part because
      ServiChangeResult is divided to CHOICE= structure

      ServiceChangeResult ::=3D = CHOICE

      {

              = errorDescriptor         &nb= sp;       ErrorDescriptor,

              = serviceChangeResParms        &nb= sp;  ServiceChangeResParm

      }


      ServiceChangeResParm ::=3D = SEQUENCE

      {

              = serviceChangeMgcId      MId OPTIONAL,

              = serviceChangeAddress    ServiceChangeAddress = OPTIONAL,

              = serviceChangeVersion    INTEGER(0..99) OPTIONAL,

      serviceChangeProfile    = ServiceChangeProfile OPTIONAL

      }




      and if ServiceChangeResParm is choosed = there migth not be any data at all in
      ServiceChangeResParm because = ServiceChangeResParm consist only from OPTIONAL
      parts.

      Br,

      Marko Onikki
      Nokia Networks
      E-mail. marko.onikki@nokia.com

------_=_NextPart_001_01BF87AD.D0FD0CC0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Mar 6 16:18:44 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02420 for ; Mon, 6 Mar 2000 16:18:43 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.08F7DE60@standards.nortelnetworks.com>; Mon, 6 Mar 2000 16:14:23 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 76437 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 16:12:51 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D2839770@standards.nortelnetworks.com>; Mon, 6 Mar 2000 16:12:51 -0500 Received: from zmers013 by smtprch1.nortel.com; Mon, 6 Mar 2000 15:10:42 -0600 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by zmers013; Mon, 6 Mar 2000 16:10:18 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 6 Mar 2000 16:10:18 -0500 X-Mailer: Internet Mail Service (5.5.2650.21) Message-ID: Date: Mon, 6 Mar 2000 16:10:15 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Summary Of Errors Found In Megaco/H.248 Protocol Document X-To: Glen Freundlich To: MEGACO@STANDARDS.NORTELNETWORKS.COM Wednesday is the end of the Last Call period for draft-ietf-megaco-protocol-07.txt. After a very quiet start, we do seem to have a small list of issues which need rectification. This is a summary for your review. Please pass any other issues you have found to the list ASAP. Issue 1. ====== Source: Shalini Philip [sphilip@FICON-TECH.COM], "Comments on V15: ABNF related", Fri 11/02/00. Section: 7.1.5 Termination State Descriptor and Annex B. Section 7.1.5 mentions the possibility of CHOOSE wildcard as one of the property values. However there is no provision for the same in the ABNF. Comments: this affects production propertyParm, which occurs in the LocalControl and TerminationState descriptors: propertyParm = pkgdName parmValue Note that the ASN.1 production for propertyParm includes CHOOSE as a possible value. It would be possible to make CHOOSE an alternative within the parmValue production, but the latter has broader scope than propertyParm: it is also found within event parameters, signal parameters, the Modem descriptor, and the ServiceChange extension parameter. The most conservative choice is therefore to modify the propertyParm production itself. Proposed resolution: change the propertyParm production to read as follows: propertyParm = pkgdName ( "$" / parmValue) Issue 2. ====== Noticed while following up on the above comment. Section: 7.1.5 Termination State Descriptor Final bullet re CHOOSE also contains material regarding the EventBufferControl property which was probably meant to be in a separate paragraph. Proposed resolution: editorial. Issue 3. ====== Noticed in the Shalini Philip E-mail and by Michael Mackey. Annex B: In the ServiceChange Descriptor, VersionToken is not defined. Proposed resolution: add a definition for VersionToken. Issue 4. ====== Noticed in the Shalini Philip E-mail. Annex B: DiscardToken is not used anywhere. Proposed resolution: remove the production for DiscardToken. Issue 5. ====== Noted by Tom Taylor, John Segers, Ameneh Zahir-Emami. Annex A: LocalControlDescriptor still contains the Reserve Boolean rather than ReserveGroup and ReserveValue. Proposed resolution: change to be consistent with the text and ABNF. Issue 6. ====== Reference: Tom Taylor, "Changes Made In Geneva", 22/02/00. Annex E section E.6.2: possible characters within the DigitString parameter should include the "Z" rather than "L" long duration modifier. Proposed resolution: fix typo. Tom Taylor Advisor -- Emerging Carrier IP Standards E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Mar 6 16:53:43 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02424 for ; Mon, 6 Mar 2000 16:18:44 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.09469AA0@standards.nortelnetworks.com>; Mon, 6 Mar 2000 16:14:23 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 76442 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 16:12:52 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D2860870@standards.nortelnetworks.com>; Mon, 6 Mar 2000 16:12:51 -0500 Received: from zmers013 by smtprch1.nortel.com; Mon, 6 Mar 2000 09:31:46 -0600 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by zmers013; Mon, 6 Mar 2000 10:29:21 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 6 Mar 2000 10:29:20 -0500 X-Mailer: Internet Mail Service (5.5.2650.21) Message-ID: Date: Mon, 6 Mar 2000 10:29:05 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: BNF X-To: Michael Mackey To: MEGACO@STANDARDS.NORTELNETWORKS.COM Thanks. Good catch. > -----Original Message----- > From: Michael Mackey [SMTP:mmackey@fore.com] > Sent: Friday, March 03, 2000 7:05 AM > To: Taylor, Tom-PT [CAR:B904:EXCH] > Subject: BNF > > Hi Tom, > Sorry if you know about this already but I found another small error > in the BNF, the version token in a service change descriptor is not > definied. > > **************************************************************** > Michael Mackey, > Marconi Communication > Tel: +353 1 2804533 x4624 > **************************************************************** From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Mar 6 23:07:12 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17906 for ; Mon, 6 Mar 2000 23:07:12 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1D691600@standards.nortelnetworks.com>; Mon, 6 Mar 2000 23:02:58 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 76900 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 23:01:35 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EBF04A80@standards.nortelnetworks.com>; Mon, 6 Mar 2000 23:01:35 -0500 Received: from zmers013 by smtprch1.nortel.com; Mon, 6 Mar 2000 21:55:51 -0600 Received: from zrchb213.us.nortel.com (actually zrchb213) by zmers013; Mon, 6 Mar 2000 22:55:35 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 6 Mar 2000 21:55:33 -0600 X-Mailer: Internet Mail Service (5.5.2650.21) Message-ID: Date: Mon, 6 Mar 2000 21:55:32 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Taking The Protocol Document Forward To: MEGACO@STANDARDS.NORTELNETWORKS.COM In accordance with our agreement with SG 16, and given that no one has brought up any show stoppers, the protocol document itself is not going to change as a result of WG Last Call except for the addition of the following sentence: "The current version of this document must be read in conjunction with draft-ietf-megaco-errata-00.txt, which lists corrections which will be incorporated into H.248 before it is decided by the ITU-T." I would like to pass draft-ietf-megaco-protocol-08.txt (the version containing this sentence) onward for IETF Last Call as soon as Brian has prepared it -- preferably by noon tomorrow (Tuesday). This is because it's best if IETF Last Call is issued by Friday, and it takes a couple of days for that to happen. If I understand the process lags correctly, we could still wait until tomorrow (Tuesday) evening before submitting draft-ietf-megaco-errata-00.txt, giving an extra half day for WG comments. Does anyone have a concern with submitting draft-ietf-megaco-protocol-08.txt to the IESG with a recommendation that it be published as a Proposed Standard? Tom Taylor Advisor -- Emerging Carrier IP Standards E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Mar 6 23:34:10 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22736 for ; Mon, 6 Mar 2000 23:34:09 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E512CBD0@standards.nortelnetworks.com>; Mon, 6 Mar 2000 23:30:02 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 76923 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 6 Mar 2000 23:28:38 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4D977540@standards.nortelnetworks.com>; Mon, 6 Mar 2000 23:18:38 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id XAA15712; Mon, 6 Mar 2000 23:22:15 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id XAA04625; Mon, 6 Mar 2000 23:22:09 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id <1WCMFY0V>; Mon, 6 Mar 2000 23:18:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF32EAEA@whq-msgusr-02.fore.com> Date: Mon, 6 Mar 2000 23:21:46 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt X-To: "Drage, Keith" To: MEGACO@STANDARDS.NORTELNETWORKS.COM I'd go the other way. If a profile did NOT specify an encoding (or failed to specify a minimum for any other option the protocol offers, I'd say it was deficient. I'll agree that subsetting where the protocol does not define an option is inappropriate. I really think that requiring an MG to have both binary and text is unworkable for a really cost constrained design. The current MGC text is not satisfactory to anyone, including me. It was a compromise, and to this day, I question it's appropriateness. Having been part of it, I'll live with it. I don't want to see these kinds of compromises in profiles, regardless of how the encoding choice comes out; profiles should result in precise interoperability for a class of devices. Any less is unworkable, IMO. Brian > -----Original Message----- > From: Drage, Keith [mailto:Keith.Drage@SIEMENSCOMMS.CO.UK] > Sent: Monday, March 06, 2000 6:01 AM > To: MEGACO@standards.nortelnetworks.com > Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt > > > The section of text encoding versus binary encoding is an > option within MG. > At the implementation level, the MG can implement one, or the > other, or > both. > > My issue is whether IETF should provide a selection of this > option within a > profile, given its agreements with ITU-T. I would be > considerably happier > with allowing this if the main MEGACO/H.248 document said > MUST (or in ITU-T > SHALL) instead of SHOULD, for the related MGC requirement. If > the IETF puts > a selection of this option at the MG in the profile, then the IETF is > effectively saying for the MGC: "the MGC MUST support text > encoding and the > MGC SHOULD support binary encoding". My understanding of the > discussion of > the encoding issue when previously discussed in both ITU-T > and IETF was that > the status was unresolvable in the standards world and would > be left to > market forces to make the decision. > > I also see no need why a MG profile should constrain the > option for this > particular application. If one encoding is so much more > complex that the > other (as some people on the list appear to think), and so > much more hungry > of hardware resources such as memory, then this one choice > will prove to be > considerably more expensive that the other and the market > will decide by not > buying the expensive one. > > In general for profiles, I have no problem with IETF creating a valid > profile for a specific application. I think including the > encoding issue > within an IETF published profile is the tricky problem. In > the draft, there > are other statements, where the protocol is subsetted, which > are not valid > for a profile. I would therefore repeat my request that MEGACO should > clearly identify in its discussions what are valid options that can be > profiled, as well as the issue of who is allowed to create > profiles. These > selectable options must be clearly based on the text that > exists in the main > MEGACO/H.248 document. > > Keith Drage > > > > --------------------------------------------------------------- > Keith Drage (keith.drage@siemenscomms.co.uk) > Siemens Communications Limited, > Technology Drive, Beeston, Nottingham NG9 1LA, UK > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > --------------------------------------------------------------- > Internet communications are not secure and therefore Siemens > Communications > Limited does not accept legal responsibility for the contents of this > message. Any views or opinions presented are solely those of > the author and > do not necessarily represent those of Siemens Communications > Limited unless > otherwise specifically stated. > > > > -----Original Message----- > From: Peter Blatherwick [mailto:blather@NORTELNETWORKS.COM] > Sent: Saturday, March 04, 2000 12:39 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt > > > > Keith, Mike, others, > > It is very definitely NOT our intent to create friction > between ITU and IETF > in our extremely admirable co-operative effort on the > H.248/Megaco protocol. > It is also not our intent to set any constraints or > precedents on how other > applications of the protocol work, whether these applications > are defined in > IETF, ITU or elsewhere. This is in no way an attempt to > side-step agreed > process. > > Our intent is to define a particular application of the > protocol, primarily > targeted at creating cost-optimized embedded devices. In > this specific > case, as with other very small scale applications, a choice > on both encoding > and transport absolutely must be made, to reduce memory > footprint. (We > would like to see other reductions as well, but let's talk about that > separately.) We chose text encoding since it seems to us > more easily and > compactly implementable for this particular application. The > transport > selection (ALF) was decided for similar pragmatic reasons. > This does not > necessarily reflect on any other application. It may well be > that we are > wrong on these choices, but a decision has to be made to move forward. > > As Brian has already noted, these are both options in the > protocol at the MG > side. Note also that the profile does not restrict use of > binary encoding > as well as text, just that the text encoding must be > implemented. The same > logic applies to transport. > > The point that we must decide where to settle definition of > this and other > applications/profiles is well taken, and I agree its at the > core of the > debate. However, I personally believe it is important to settle some > specific applications of the protocol soon, leading towards > interoperability > testing and validation, which are natural parts of the IETF > side of the > joint process. Then again, I'm no process guru... > > I hope that helps, and apologize for not making it more clear > up front. > > Peter Blatherwick > > -----Original Message----- > From: Mike Buckley [SMTP:mikebuckley@ATTMAIL.COM] > Sent: Friday, March 03, 2000 8:35 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt > > I agree wholeheartedly with Keith Drage's comment: > > >Surely it also dishonours the agreement between the > ITU-T and IETF > groups, > >as they participated in agreeing the words that go in > H.248/MEGACO, but do > >not apparently participate in discussing the profile that then gets > >subsequently published by IETF. > > This attempt to sidestep the agreement with the ITU > can only create > bad faith > between the two organizations. The Megaco wording was > arrived at after > lengthy > discussions and compromise on both sides. The consequences > of unilaterally > trying to pursue one line will ony result in the ITU going off in an > incompatible > direction. Is this what the market wants - an IETF package > specifying text > encoding and an ITU Annex specifying binary? > > This is not the way to resolve the text v. binary > issue and it is > not the way to built > good relations between the two Standards bodies. > > Agreements should be honoured by both sides in the > spirit as well as > the letter. > > Mike Buckley > > > ____________________ Begin Original Message > ___________________________ > Date: Fri Mar 3 08:05:04 -0500 2000 > From: internet!FORE.COM!brosen (Rosen, Brian) > Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt > To: internet!STANDARDS.NORTELNETWORKS.COM!MEGACO > Content-Type: Generic-Text > Content-Length: 5599 > > There are two threads in this message I wish to comment on. > 1. The issue of text encoding. Text/Binary Encoding is defined > in the protocol as optional. A profile could make a choice. > It is acceptable to me that such a choice be made in this profile. > > 2. Subsets of the protocol. I have been vociferous > in positing > that profiles cannot subset the protocol. If the protocol > defines something as optional, then the profile can declare > what options shall be implemented. Where there is not an option, > profiles should not make something optional. If it does, it's > a new protocol. Call it that, and we can decide if we want > to standardize a new protocol. I personally do not believe that > an IPPhone needs to subset the Megaco protocol. > > Brian > > > > > -----Original Message----- > > From: Drage, Keith [ mailto:Keith.Drage@SIEMENSCOMMS.CO.UK > ] > > Sent: Friday, March 03, 2000 4:43 AM > > To: MEGACO@standards.nortelnetworks.com > > Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt > > > > > > I note that this proposed profile contains the text: > > > > "Megaco IP Phone MGs MUST support text encoding of the protocol, as > > specified in the Megaco/H.248 Protocol document [3]." > > > > While I DO NOT want to reopen the encoding debate, it seems > > inappropriate to > > me that MEGACO should create a profile that further restricts it own > > product. I understood the summary of the text versus binary > > debate was that > > the decision on encoding would be made by market forces, and was NOT > > application dependent. If there is an application dependency, then > > guidelines to that dependency should surely be given in the > > main MEGACO > > protocol document. > > > > Surely it also dishonours the agreement between the ITU-T and > > IETF groups, > > as they participated in agreeing the words that go in > > H.248/MEGACO, but do > > not apparently participate in discussing the profile that then gets > > subsequently published by IETF. > > > > I would have therefore thought that if TIA wish to restrict > > the encoding > > choice, then it is up to TIA to publish the profile, rather > > than the IETF. > > > > Looking further, I notice that the document also defines > > constraints on the > > usage of Events, etc. Reading the main MEGACO protocol document, I > > understand that variations on termination characteristics should be > > implemented by specification of a package. Should these restrictions > > therefore be defined by a new package? > > > > I guess we need some general discussion on what is possible > > in profiles, as > > opposed to packages, and whether MEGACO should define > > profiles that are > > still nominally called MEGACO, but do not exhibit all the > > requirements of > > the main document. Rephrasing in a slightly different way, > > which are the > > options, and which of these options that are selected based > > on the type of > > application (and therefore suitable for specification in > > profiles for a > > particular application), and which are implementation options > > (and selected > > because an implementor wishes to make his product different > > and presumably > > better/cheaper/fit the available memory than another market > entrant). > > > > Rephrasing the question a different way, with the > > restrictions imposed by > > this "profile", can the result still be MEGACO/H.248, or > has it really > > invented a new protocol? > > > > Let me stress again, I do not want to see any responses that > > it is done this > > way because text is better than binary, or more efficient. > > The answer to > > that is irrelevant to the point I am trying to make. > > > > Keith Drage > > > > > > > --------------------------------------------------------------- > > > Keith Drage (keith.drage@siemenscomms.co.uk) > > > Siemens Communications Limited, > > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > > --------------------------------------------------------------- > > > Internet communications are not secure and therefore Siemens > > > Communications Limited does not accept legal > responsibility for the > > > contents of this message. Any views or opinions presented > are solely > > > those of the author and do not necessarily represent those > > of Siemens > > > Communications Limited unless otherwise specifically stated. > > > > > > 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 IP Phone Media Gateway > > > Application Profile > > > Author(s) : R. Bell, P. Blatherwick, P. Holland > > > Filename : draft-ietf-megaco-ipphone-02.txt > > > Pages : 13 > > > Date : 01-Mar-00 > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-ietf-megaco-ipphone-02.txt > > > > > > > > > > > --------------------------------------------------------------- > > > Keith Drage (keith.drage@siemenscomms.co.uk) > > > Siemens Communications Limited, > > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > > --------------------------------------------------------------- > > > Internet communications are not secure and therefore Siemens > > > Communications Limited does not accept legal > responsibility for the > > > contents of this message. Any views or opinions presented > > are solely those > > > of the author and do not necessarily represent those of Siemens > > > Communications Limited unless otherwise specifically stated. > > > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 7 07:32:05 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13219 for ; Tue, 7 Mar 2000 07:32:05 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9EB18A80@standards.nortelnetworks.com>; Tue, 7 Mar 2000 7:27:40 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 77391 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 07:26:44 -0500 Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7C6E06B0@standards.nortelnetworks.com>; Tue, 7 Mar 2000 7:26:42 -0500 Received: from ficon-tech.com (sphilip.india.ficon-tech.com [172.25.1.104]) by ficon-tech.com (8.9.3/8.8.7) with ESMTP id RAA34694 for ; Tue, 7 Mar 2000 17:54:35 +0530 (IST) (envelope-from sphilip@ficon-tech.com) X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38C4F613.C562FEF3@ficon-tech.com> Date: Tue, 7 Mar 2000 17:59:07 +0530 Reply-To: Shalini Philip Sender: "Media Gateway Control (megaco)" From: Shalini Philip Organization: Ficon Technology Subject: Issues in V16 Draft To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Brian/Tom, There is some clarification required on some of the latest changes in V16 draft. They are: 1. Section 11.2 on Cold Start says that : "Upon failure to obtain a reply, either from the Primary MGC, or a designated successor, the MG tries its pre-provisioned Secondary MGCs, in order. If the MG is unable to comply and it has established a transport connection to the MGC, it should close that connection. In any event, it should reject all subsequent requests from the MGC with Error 406 Version Not Supported." The situation of MG not being able to comply and sending errors of Version not supported, seems to be appropriate only for the case of Version negotiation failure and not as a general case. If MG is unable to comply due to some other reason, then the appropriate error should be returned. 2. In Section 7.2.5, it is clarified that if DigitMap is requested in an AuditValue command with TerminationID ALL, then all the digit maps defined in the gateway are returned. Since only the digit map names are getting returned here, it would not be possible to return those digit maps specified by MGC as part of the Event Descriptor, since they do not have names associated with them. Regards, Shalini Philip Ficon Technology E-Mail : mailto:sphilip@ficon-tech.com Web : http://www.ficon-tech.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 7 07:34:15 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13650 for ; Tue, 7 Mar 2000 07:34:14 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E7621790@standards.nortelnetworks.com>; Tue, 7 Mar 2000 7:29:42 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 77412 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 07:29:05 -0500 Received: from mailboy.huawei.com.cn (202.96.135.134) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D02C9FF0@standards.nortelnetworks.com>; Tue, 7 Mar 2000 7:29:03 -0500 Received: from q17326 ([10.105.30.242]) by mailboy.huawei.com.cn (Netscape Mail Server v2.02) with SMTP id AAA12768 for ; Tue, 7 Mar 2000 20:19:46 +0800 X-mailer: FoxMail 3.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Message-ID: <20000307121946.AAA12768@q17326> Date: Tue, 7 Mar 2000 20:26:41 +0800 Reply-To: Xiuping Qiu Sender: "Media Gateway Control (megaco)" From: Xiuping Qiu Organization: Huawei Technologies Subject: Questions on MEGACO/H.248 v16 - More To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA13650 Hi, all Thanks for those who reponses me. Also thanks for you who reads my questions. 1. When ReserveValue and ReserveGroup are true , how the parameters of Value and Group are matched? And if ReserveValue and ReserveGroup are true, will it return large numbers of info? For example,if ReserveValue is true,and there is a "m=audio $ RTP/AVP 0 " line in Local Descriptor,then should MG return all possible port numbers to MGC? 2. In 7.1.8 Local and Remote Descriptors (a) An unspecified Local or Remote descriptor is considered to be a missing mandatory parameter. It requires the MG to use whatever was last specified for that descriptor. It is possible that there was no previously-specified value, in which case the descriptor concerned is ignored in further processing of the command. It seems that the above conflicts with the Example of Appendix A. 3. “ If the Mode property of the LocalControl descriptor is RecvOnly or SendRecv, the MG must be prepared to receive media encoded according to any of the alternatives included in its response to the MGC. “ Question :What exact alternative does MG use to receive media? e.g. When the peer MG has sent media encoded in one of the alternatives,how does the prepared MG know what type is the encoding? 4. E.6.2 Events Original: Termination Method ParameterID: Meth (0x0003) Type: enumeration Possible values: "UM" (0x0001) Unambiguous match "PM" (0x0002) Partial match, completion by timer expiry or unmatched event "FM" (0x0003) Full match, completion by timer expiry or unmatched event Description: indicates the reason for generation of the event. See the procedures in section . Question £º While dialing the MG detects the onhook events, then will it happen the DigitMapCompletion event? If it happens, what the kind of Termination Method is ? And, Which event happens first ? Onhook or DigitMap Completion? 5. 7.1.9 Events Descriptor Question: In Case 1, EventBufferControl = LockStep £¬EventBuffer is empty£¬Will EventDescriptor and EventBufferDescriptor both work ? If they both work, suppose one event exists in both Descriptors, Then how to deal with it ? 6. Question: Before replaced by a new one, can an EventDescriptor be used to detect specified events more than once? I.e. One EventDescriptor contains an EventID dt , after detected once, if event dt happened again , and the EventDescriptor is not replaced. Will the MG Notify the event? Thanks, Xiuping Qiu _______________________________________________ Xiuping Qiu Huawei Technologies Co., Ltd. Mail to: qiuxiuping@sz.huawei.com.cn Tel : +86 755 6544482 Visit : http://www.huawei.com.cn _______________________________________________ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 7 08:21:33 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23674 for ; Tue, 7 Mar 2000 08:21:33 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8171E260@standards.nortelnetworks.com>; Tue, 7 Mar 2000 8:16:57 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 77553 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 08:15:38 -0500 Received: from mailboy.huawei.com.cn (202.96.135.134) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.51041E40@standards.nortelnetworks.com>; Tue, 7 Mar 2000 8:15:36 -0500 Received: from q17326 ([10.105.30.242]) by mailboy.huawei.com.cn (Netscape Mail Server v2.02) with SMTP id AAA14744; Tue, 7 Mar 2000 21:13:00 +0800 X-mailer: FoxMail 3.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Message-ID: <20000307131300.AAA14744@q17326> Date: Tue, 7 Mar 2000 21:19:54 +0800 Reply-To: Xiuping Qiu Sender: "Media Gateway Control (megaco)" From: Xiuping Qiu Organization: Huawei Technologies Subject: Re: Questions About MEGACO/H.248 Version 16 X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, Tom-PT Taylor ,list Still question on stream. May StreamDescriptor describe streams between terminations in a same context? If so, I think there are at least 2 streams within a termination. One stream flows to the exterior of the context , the other flows to other termination, In the figure below, termination T1 has 2 streams : S1 and S3. And termination T2 has S2 and S4. S1 flows to the exterior of the context, S3 flows to other termination. I wonder the relationships of S1,S2,S3,S4 if T1 and T2 are connected. such as which are specified by StreamID , the equal relationship , which equals to which then the streams aare connected, and so on. +------------------------------------+ | Context | | | S1 | +----+ S3 S4 +----+ | S2 ----------- | |------*---- | |------------- | | T1 | | T2 | | | +----+ +----+ | | | +------------------------------------+ >> 2. In 7.1.6 Stream Descriptor >> >> " StreamIDs are of local significance between MGC and MG and they are >> assigned by the MGC. Within a context, StreamID is a means by which to >> indicate which media flows are interconnected: streams with the same >> StreamID are connected " >> >> I am wondering whether StreamID will conflict with Topology. >> >> Let's suppose there are 2 Terminations ( T1 and T2) in a context . There >> is one stream on the 2 Terminations each but the StreamIDs are different. >> So the media flows are not interconnected. But if the Topology Descriptor >> of the Context is >> Bothway", What will happen? > [[TomT]] > Topology is sort of a global property -- it defines >inter-termination connectivity regardless of the details of which streams >are flowing. Streams add a level of detail within that framework: A may >talk to B in general, but B doesn't happen to support the video that A is >prepared to provide. One could conceive of making topology stream-specific, >but I don't think there's a real requirement for that level of control. > Regards, Xiuping Qiu _______________________________________________ Xiuping Qiu Huawei Technologies Co., Ltd. Mail to: qiuxiuping@sz.huawei.com.cn Tel : +86 755 654 4482 Visit : http://www.huawei.com.cn _______________________________________________ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 7 10:10:30 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19620 for ; Tue, 7 Mar 2000 10:10:30 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C4151100@standards.nortelnetworks.com>; Tue, 7 Mar 2000 10:06:12 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 77730 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 10:05:00 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3395E7E0@standards.nortelnetworks.com>; Tue, 7 Mar 2000 9:55:00 -0500 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id GAA07535 for ; Tue, 7 Mar 2000 06:58:44 -0800 (PST) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38C51A06.DAE1FAFE@cisco.com> Date: Tue, 7 Mar 2000 10:02:30 -0500 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Subject: Event handling questions To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit A couple of questions on the event handling (7.1.9): 1. It is specified that "When the MG receives a command with a new EventsDescriptor, one or more events may have been buffered in the EventBuffer in the MG. The value of EventBufferControl then determines how the MG treats such buffered events." I assume that the "the value of EventBufferControl" refers to the value in the new command (if supplied), not the old, correct ? 2. It is specified that "If the MG receives a command instructing it to set the value of EventBufferControl to Off, all events in the EventBuffer SHALL be discarded." This seems rather strange to me as you will be dropping events for no apparent reason. Can somebody please explain the rationale behind this ? Thanks Flemming -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 7 10:34:38 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25359 for ; Tue, 7 Mar 2000 10:34:38 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.215E9180@standards.nortelnetworks.com>; Tue, 7 Mar 2000 10:30:17 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 77796 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 10:29:04 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F5CD4F20@standards.nortelnetworks.com>; Tue, 7 Mar 2000 10:29:03 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 7 Mar 2000 09:07:53 -0600 Received: from zrchb213.us.nortel.com (actually zrchb213) by zmers013; Tue, 7 Mar 2000 10:06:52 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 7 Mar 2000 09:06:49 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8846.C210A624" Message-ID: <29400B68197CD31188830000F8CD15D343BC90@zcard00q.ca.nortel.com> Date: Tue, 7 Mar 2000 09:06:46 -0600 Reply-To: Peter Blatherwick Sender: "Media Gateway Control (megaco)" From: Peter Blatherwick Subject: Re: Taking The Protocol Document Forward X-To: Tom-PT Taylor 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_01BF8846.C210A624 Content-Type: text/plain My only concern would be if it were NOT submitted! Lots of things I'd make different for my particular needs, of course, but its a good set of compromises overall. The most important thing right now is to move forward. Congratulations to all who have made this possible. -- Peter Blatherwick > -----Original Message----- > From: Taylor, Tom-PT [CAR:B904:EXCH] > Sent: 6 Mar, 2000 22:56 > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Taking The Protocol Document Forward > > In accordance with our agreement with SG 16, and given that no one has > brought up any show stoppers, the protocol document itself is not going to > change as a result of WG Last Call except for the addition of the > following > sentence: > > "The current version of this document must be read in conjunction with > draft-ietf-megaco-errata-00.txt, which lists corrections which will be > incorporated into H.248 before it is decided by the ITU-T." > > I would like to pass draft-ietf-megaco-protocol-08.txt (the version > containing this sentence) onward for IETF Last Call as soon as Brian has > prepared it -- preferably by noon tomorrow (Tuesday). This is because > it's > best if IETF Last Call is issued by Friday, and it takes a couple of days > for that to happen. If I understand the process lags correctly, we could > still wait until tomorrow (Tuesday) evening before submitting > draft-ietf-megaco-errata-00.txt, giving an extra half day for WG comments. > > Does anyone have a concern with submitting > draft-ietf-megaco-protocol-08.txt > to the IESG with a recommendation that it be published as a Proposed > Standard? > > Tom Taylor > Advisor -- Emerging Carrier IP Standards > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) > Phone and FAX: +1 613 736 0961 ------_=_NextPart_001_01BF8846.C210A624 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Taking The Protocol Document Forward

My only concern = would be if it were NOT submitted!  Lots of things I'd make = different for my particular needs, of course, but its a good set of = compromises overall.  The most important thing right now is to = move forward. 

Congratulations to = all who have made this possible. 

-- Peter = Blatherwick

    -----Original Message-----
    From:   Taylor, Tom-PT [CAR:B904:EXCH]
    Sent:   6 Mar, 2000 22:56
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Taking The Protocol Document = Forward

    In accordance with our agreement with = SG 16, and given that no one has
    brought up any show stoppers, the = protocol document itself is not going to
    change as a result of WG Last Call = except for the addition of the following
    sentence:

    "The current version of this = document must be read in conjunction with
    draft-ietf-megaco-errata-00.txt, = which lists corrections which will be
    incorporated into H.248 before it is = decided by the ITU-T."

    I would like to pass = draft-ietf-megaco-protocol-08.txt (the version
    containing this sentence) onward for = IETF Last Call as soon as Brian has
    prepared it -- preferably by noon = tomorrow (Tuesday).  This is because it's
    best if IETF Last Call is issued by = Friday, and it takes a couple of days
    for that to happen.  If I = understand the process lags correctly, we could
    still wait until tomorrow (Tuesday) = evening before submitting
    draft-ietf-megaco-errata-00.txt, = giving an extra half day for WG comments.

    Does anyone have a concern with = submitting draft-ietf-megaco-protocol-08.txt
    to the IESG with a recommendation = that it be published as a Proposed
    Standard?

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

------_=_NextPart_001_01BF8846.C210A624-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 7 10:54:37 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29722 for ; Tue, 7 Mar 2000 10:54:36 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EE18C6D0@standards.nortelnetworks.com>; Tue, 7 Mar 2000 10:50:19 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 77828 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 10:48:33 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AEEF30C0@standards.nortelnetworks.com>; Tue, 7 Mar 2000 10:48:33 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 7 Mar 2000 09:48:11 -0600 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by zmers013; Tue, 7 Mar 2000 10:47:43 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 7 Mar 2000 10:47:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF884C.7A1BA5AC" Message-ID: Date: Tue, 7 Mar 2000 10:47:40 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Event handling questions X-To: Flemming Andreasen 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_01BF884C.7A1BA5AC Content-Type: text/plain Replies below. > -----Original Message----- > From: Flemming Andreasen [SMTP:fandreas@CISCO.COM] > Sent: Tuesday, March 07, 2000 10:03 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Event handling questions > > A couple of questions on the event handling (7.1.9): > > 1. It is specified that "When the MG receives a command with a new > EventsDescriptor, one or more events may have been buffered in the > EventBuffer in the MG. The value of EventBufferControl then determines > how the MG treats such buffered events." > > I assume that the "the value of EventBufferControl" refers to the value > in the new command (if supplied), not the old, correct ? [[TomT]] That is correct. > 2. It is specified that "If the MG receives a command instructing it to > set the value of EventBufferControl to Off, all events in the > EventBuffer SHALL be discarded." > > This seems rather strange to me as you will be dropping events for no > apparent reason. Can somebody please explain the rationale behind this ? > [[TomT]] If the MGC turns EventBufferControl off, it must have a reason for doing so. The same reason presumably extends to the treatment of events already in the buffer. > Thanks > > Flemming > > -- > Flemming Andreasen > Cisco Systems ------_=_NextPart_001_01BF884C.7A1BA5AC Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Event handling questions

Replies = below.

    -----Original Message-----
    From:   Flemming Andreasen = [SMTP:fandreas@CISCO.COM]
    Sent:   Tuesday, March 07, 2000 10:03 AM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Event handling questions

    A couple of questions on the event = handling (7.1.9):

    1. It is specified that "When the = MG receives a command with a new
    EventsDescriptor, one or more events = may have been buffered in the
    EventBuffer in the MG. The value of = EventBufferControl then determines
    how the MG treats such buffered = events."

    I assume that the "the value of = EventBufferControl" refers to the value
    in the new command (if supplied), not = the old, correct ?
    [[TomT]] 
    That is = correct.


    2. It is specified that "If the = MG receives a command instructing it to
    set the value of EventBufferControl = to Off, all events in the
    EventBuffer SHALL be = discarded."

    This seems rather strange to me as you = will be dropping events for no
    apparent reason. Can somebody please = explain the rationale behind this ?

    [[TomT]]  If the MGC turns = EventBufferControl off, it must have a reason for doing so.  The = same reason presumably extends to the treatment of events already in = the buffer.


    Thanks

            = Flemming

    --
    Flemming Andreasen
    Cisco Systems

------_=_NextPart_001_01BF884C.7A1BA5AC-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 7 10:59:36 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00533 for ; Tue, 7 Mar 2000 10:59:35 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A255D430@standards.nortelnetworks.com>; Tue, 7 Mar 2000 10:55:21 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 77824 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 10:53:48 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.05204610@standards.nortelnetworks.com>; Tue, 7 Mar 2000 10:43:48 -0500 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id HAA21933; Tue, 7 Mar 2000 07:47:30 -0800 (PST) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38C52571.A39987EE@cisco.com> Date: Tue, 7 Mar 2000 10:51:13 -0500 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Subject: Re: Taking The Protocol Document Forward X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Well, on 2/22/00 you sent out an e-mail that WG last ends on March 8th and I for one am still operating under that assumption. I suspect others probably are as well. Regards Flemming Tom-PT Taylor wrote: > In accordance with our agreement with SG 16, and given that no one has > brought up any show stoppers, the protocol document itself is not going to > change as a result of WG Last Call except for the addition of the following > sentence: > > "The current version of this document must be read in conjunction with > draft-ietf-megaco-errata-00.txt, which lists corrections which will be > incorporated into H.248 before it is decided by the ITU-T." > > I would like to pass draft-ietf-megaco-protocol-08.txt (the version > containing this sentence) onward for IETF Last Call as soon as Brian has > prepared it -- preferably by noon tomorrow (Tuesday). This is because it's > best if IETF Last Call is issued by Friday, and it takes a couple of days > for that to happen. If I understand the process lags correctly, we could > still wait until tomorrow (Tuesday) evening before submitting > draft-ietf-megaco-errata-00.txt, giving an extra half day for WG comments. > > Does anyone have a concern with submitting draft-ietf-megaco-protocol-08.txt > to the IESG with a recommendation that it be published as a Proposed > Standard? > > Tom Taylor > Advisor -- Emerging Carrier IP Standards > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) > Phone and FAX: +1 613 736 0961 -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 7 11:11:42 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02225 for ; Tue, 7 Mar 2000 11:11:41 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5133CCE0@standards.nortelnetworks.com>; Tue, 7 Mar 2000 11:07:24 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 77870 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 11:06:48 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D5D19BA0@standards.nortelnetworks.com>; Tue, 7 Mar 2000 10:56:48 -0500 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id IAA26002; Tue, 7 Mar 2000 08:00:33 -0800 (PST) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38C52880.878D48A7@cisco.com> Date: Tue, 7 Mar 2000 11:04:16 -0500 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Subject: Re: Event handling questions X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Tom-PT Taylor wrote: > > > Replies below. > > -----Original Message----- > From: Flemming Andreasen [SMTP:fandreas@CISCO.COM] > Sent: Tuesday, March 07, 2000 10:03 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Event handling questions > > A couple of questions on the event handling (7.1.9): > > 1. It is specified that "When the MG receives a command with a > new > EventsDescriptor, one or more events may have been buffered in > the > EventBuffer in the MG. The value of EventBufferControl then > determines > how the MG treats such buffered events." > > I assume that the "the value of EventBufferControl" refers to the > value > in the new command (if supplied), not the old, correct ? > [[TomT]] > That is correct. > > 2. It is specified that "If the MG receives a command instructing > it to > set the value of EventBufferControl to Off, all events in the > EventBuffer SHALL be discarded." > > This seems rather strange to me as you will be dropping events > for no > apparent reason. Can somebody please explain the rationale behind > this ? > > [[TomT]] If the MGC turns EventBufferControl off, it must have a > reason for doing so. The same reason presumably extends to the > treatment of events already in the buffer. > I don't follow. How does that justify throwing away the events that were already buffered ? The only thing you are changing is the way you report events. For example consider the case where the set of events to be detected in the two commands are exactly the same but the EventBufferControl differs. > > Thanks > > Flemming > > -- > Flemming Andreasen > Cisco Systems > -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 7 11:33:52 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05298 for ; Tue, 7 Mar 2000 11:33:49 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.65A69AB0@standards.nortelnetworks.com>; Tue, 7 Mar 2000 11:29:27 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 77925 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 11:28:21 -0500 Received: from relay.mail.pipex.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3E5BB490@standards.nortelnetworks.com>; Tue, 7 Mar 2000 11:28:21 -0500 Received: (qmail 18940 invoked from network); 7 Mar 2000 16:32:09 -0000 Received: from gatekeeper.sgcs.co.uk (HELO bevx03.gpt.co.uk) (194.129.217.113) by iprelay.mail.pipex.net with SMTP; 7 Mar 2000 16:32:09 -0000 Received: from CONVERSION-DAEMON by siemenscomms.co.uk (PMDF V5.1-12 #D3115) id <01JMRAK0JVOG90NMN8@siemenscomms.co.uk> for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 16:25:48 GMT Received: from beex01.sgcs.co.uk ([19.0.53.101]) by siemenscomms.co.uk (PMDF V5.1-12 #D3115) with ESMTP id <01JMRAJWD1I890NZ58@siemenscomms.co.uk> for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 07 Mar 2000 16:25:41 +0000 (GMT) Received: by beex01.sgcs.co.uk with Internet Mail Service (5.5.2448.0) id ; Tue, 07 Mar 2000 16:29:34 +0000 Content-return: allowed MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Message-ID: <5AC7D3F55147D311AA1700A0C99583ED2C3693@beex03.sgcs.co.uk> Date: Tue, 7 Mar 2000 16:29:28 +0000 Reply-To: "Drage, Keith" Sender: "Media Gateway Control (megaco)" Comments: *********************************************** Comments: * Our domain is now siemenscomms.co.uk * Comments: * Please update your address book accordingly * Comments: *********************************************** From: "Drage, Keith" Subject: Comments on MEGACO protocol To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7BIT Attached please find a number of editorial comments on the Geneva output document, which we also understand is identical to the MEGACO last call document. These points are not intended to be controversial. In the event that discussion is required to resolve such a comment, then we will withdraw the comment in order to allow the document to proceed. 1) Abbreviations. "BRI" is never used and therefore should be removed from the list of abbreviations. 2) References. Q.724 is never used and should be removed. 3) References and annex C. Where a reference is only used in annex C, we believe in general in most cases these should be undated (i.e. the latest version of the referenced document applies). This in particular applies to Q.931, Q. 2931, Q.763 where ITU-T SG11 have no intention of changing codepoints to different values, but do reserve the right to add new values. Surely the whole ethos of annex C is that new values do get automatically incorporated. 4) References (and annex C if comment 3 not accepted). Some of the dates are incorrect. Q.761-4 have a date of December 1999 as that was decided last year. Q.2931 should reflect the date of the latest amendment (4) which we believe is also December 1999. 5) Annex A. We could not find the module header, or an exports statement, for the ASN.1. The module header is mandatory parts of the ASN.1, and gives that module an object identifier, which is needed for inport to anything else. 6) Annex C, C.8, generic identifier transport. We are not sure how you fit this into four octets. Is there some subset of the generic identifier transport information element that is being used? Various codings of this information element get very, very long. 7) Annex C, C.9, ITC has a reference to a note 2, which is not in the table. Is this a spurious inport from the referenced standard? If so, we believe it can be deleted. 8) Annex C, C.9. References to Q.931 need to identify that the references are to the encoding in the Bearer capability information element, and not to the Low layer information element. The latter has identical fields with the same code values, but has a more extensive range of values assigned. This is because some values (particularly at layer 3) are only defined for end user to addressed end user usage. I believe in H.248 only the more restricted list in the Bearer capability information element would be valid. Keith Drage > --------------------------------------------------------------- > Keith Drage (keith.drage@siemenscomms.co.uk) > Siemens Communications Limited, > Technology Drive, Beeston, Nottingham NG9 1LA, UK > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > --------------------------------------------------------------- > Internet communications are not secure and therefore Siemens > Communications Limited does not accept legal responsibility for the > contents of this message. Any views or opinions presented are solely those > of the author and do not necessarily represent those of Siemens > Communications Limited unless otherwise specifically stated. > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 7 11:41:55 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06403 for ; Tue, 7 Mar 2000 11:41:49 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.84DC9AF0@standards.nortelnetworks.com>; Tue, 7 Mar 2000 11:37:29 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 77951 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 11:35:51 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4A96B290@standards.nortelnetworks.com>; Tue, 7 Mar 2000 11:35:51 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 7 Mar 2000 10:28:11 -0600 Received: from zrchb213.us.nortel.com (actually zrchb213) by zmers013; Tue, 7 Mar 2000 11:27:56 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 7 Mar 2000 10:27:53 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8852.168065F4" Message-ID: Date: Tue, 7 Mar 2000 10:27:54 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Taking The Protocol Document Forward X-To: Flemming Andreasen 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_01BF8852.168065F4 Content-Type: text/plain Flemming, Scott's current proposal is that we put the current -07 draft forward for IETF Last Call because we don't have time to wait for the -08 draft and the errata document to appear. Would you (and anyone else) object to doing that, provided that the errata document is not submitted until after tomorrow so it can include any comments received then? > -----Original Message----- > From: Flemming Andreasen [SMTP:fandreas@cisco.com] > Sent: Tuesday, March 07, 2000 10:51 AM > To: Taylor, Tom-PT [CAR:B904:EXCH] > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Taking The Protocol Document Forward > > Well, on 2/22/00 you sent out an e-mail that WG last ends on March 8th and > I for > one am still operating under that assumption. I suspect others probably > are as > well. > > Regards > > Flemming > > > > Tom-PT Taylor wrote: > > > In accordance with our agreement with SG 16, and given that no one has > > brought up any show stoppers, the protocol document itself is not going > to > > change as a result of WG Last Call except for the addition of the > following > > sentence: > > > > "The current version of this document must be read in conjunction with > > draft-ietf-megaco-errata-00.txt, which lists corrections which will be > > incorporated into H.248 before it is decided by the ITU-T." > > > > I would like to pass draft-ietf-megaco-protocol-08.txt (the version > > containing this sentence) onward for IETF Last Call as soon as Brian has > > prepared it -- preferably by noon tomorrow (Tuesday). This is because > it's > > best if IETF Last Call is issued by Friday, and it takes a couple of > days > > for that to happen. If I understand the process lags correctly, we > could > > still wait until tomorrow (Tuesday) evening before submitting > > draft-ietf-megaco-errata-00.txt, giving an extra half day for WG > comments. > > > > Does anyone have a concern with submitting > draft-ietf-megaco-protocol-08.txt > > to the IESG with a recommendation that it be published as a Proposed > > Standard? > > > > Tom Taylor > > Advisor -- Emerging Carrier IP Standards > > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) > > Phone and FAX: +1 613 736 0961 > > -- > Flemming Andreasen > Cisco Systems > > ------_=_NextPart_001_01BF8852.168065F4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Taking The Protocol Document Forward

Flemming, Scott's = current proposal is that we put the current -07 draft forward for IETF = Last Call because we don't have time to wait for the -08 draft and the = errata document to appear.  Would you (and anyone else) object to = doing that, provided that the errata document is not submitted until = after tomorrow so it can include any comments received then?

    -----Original Message-----
    From:   Flemming Andreasen = [SMTP:fandreas@cisco.com]
    Sent:   Tuesday, March 07, 2000 10:51 AM
    To:     Taylor, Tom-PT [CAR:B904:EXCH]
    Cc:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: Taking The Protocol Document = Forward

    Well, on 2/22/00 you sent out an = e-mail that WG last ends on March 8th and I for
    one am still operating under that = assumption. I suspect others probably are as
    well.

    Regards

            = Flemming



    Tom-PT Taylor wrote:

    > In accordance with our agreement = with SG 16, and given that no one has
    > brought up any show stoppers, = the protocol document itself is not going to
    > change as a result of WG Last = Call except for the addition of the following
    > sentence:
    >
    > "The current version of = this document must be read in conjunction with
    > draft-ietf-megaco-errata-00.txt, = which lists corrections which will be
    > incorporated into H.248 before = it is decided by the ITU-T."
    >
    > I would like to pass = draft-ietf-megaco-protocol-08.txt (the version
    > containing this sentence) onward = for IETF Last Call as soon as Brian has
    > prepared it -- preferably by = noon tomorrow (Tuesday).  This is because it's
    > best if IETF Last Call is issued = by Friday, and it takes a couple of days
    > for that to happen.  If I = understand the process lags correctly, we could
    > still wait until tomorrow = (Tuesday) evening before submitting
    > draft-ietf-megaco-errata-00.txt, = giving an extra half day for WG comments.
    >
    > Does anyone have a concern with = submitting draft-ietf-megaco-protocol-08.txt
    > to the IESG with a = recommendation that it be published as a Proposed
    > Standard?
    >
    > Tom Taylor
    > Advisor -- Emerging Carrier IP = Standards
    > E-mail: = taylor@nortelnetworks.com (internally, Tom-PT Taylor)
    > Phone and FAX: +1 613 736 = 0961

    --
    Flemming Andreasen
    Cisco Systems


------_=_NextPart_001_01BF8852.168065F4-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 7 12:00:57 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10311 for ; Tue, 7 Mar 2000 12:00:56 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.31F854C0@standards.nortelnetworks.com>; Tue, 7 Mar 2000 11:56:38 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 78006 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 11:55:04 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.93F0F7B0@standards.nortelnetworks.com>; Tue, 7 Mar 2000 11:45:04 -0500 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id IAA13983; Tue, 7 Mar 2000 08:48:49 -0800 (PST) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38C533CB.A33C5EF@cisco.com> Date: Tue, 7 Mar 2000 11:52:27 -0500 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Subject: Re: Taking The Protocol Document Forward X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I am not concerned about process issues. As long as the net result is that we can still provide comments for due consideration through tomorrow I'm fine with that. Regards Flemming Tom-PT Taylor wrote: > > > Flemming, Scott's current proposal is that we put the current -07 > draft forward for IETF Last Call because we don't have time to wait > for the -08 draft and the errata document to appear. Would you (and > anyone else) object to doing that, provided that the errata document > is not submitted until after tomorrow so it can include any comments > received then? > > -----Original Message----- > From: Flemming Andreasen [SMTP:fandreas@cisco.com] > Sent: Tuesday, March 07, 2000 10:51 AM > To: Taylor, Tom-PT [CAR:B904:EXCH] > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Taking The Protocol Document Forward > > Well, on 2/22/00 you sent out an e-mail that WG last ends on > March 8th and I for > one am still operating under that assumption. I suspect others > probably are as > well. > > Regards > > Flemming > > > Tom-PT Taylor wrote: > > > In accordance with our agreement with SG 16, and given that no > one has > > brought up any show stoppers, the protocol document itself is > not going to > > change as a result of WG Last Call except for the addition of > the following > > sentence: > > > > "The current version of this document must be read in > conjunction with > > draft-ietf-megaco-errata-00.txt, which lists corrections which > will be > > incorporated into H.248 before it is decided by the ITU-T." > > > > I would like to pass draft-ietf-megaco-protocol-08.txt (the > version > > containing this sentence) onward for IETF Last Call as soon as > Brian has > > prepared it -- preferably by noon tomorrow (Tuesday). This is > because it's > > best if IETF Last Call is issued by Friday, and it takes a > couple of days > > for that to happen. If I understand the process lags > correctly, we could > > still wait until tomorrow (Tuesday) evening before submitting > > draft-ietf-megaco-errata-00.txt, giving an extra half day for > WG comments. > > > > Does anyone have a concern with submitting > draft-ietf-megaco-protocol-08.txt > > to the IESG with a recommendation that it be published as a > Proposed > > Standard? > > > > Tom Taylor > > Advisor -- Emerging Carrier IP Standards > > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) > > Phone and FAX: +1 613 736 0961 > > -- > Flemming Andreasen > Cisco Systems > > -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 7 12:33:00 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16431 for ; Tue, 7 Mar 2000 12:32:58 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AE921440@standards.nortelnetworks.com>; Tue, 7 Mar 2000 12:28:45 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 78160 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 12:27:41 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.88679240@standards.nortelnetworks.com>; Tue, 7 Mar 2000 12:27:41 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 7 Mar 2000 11:29:37 -0600 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by zmers013; Tue, 7 Mar 2000 12:29:05 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 7 Mar 2000 12:29:05 -0500 X-Mailer: Internet Mail Service (5.5.2650.21) Message-ID: Date: Tue, 7 Mar 2000 12:29:01 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: IETF Last Call For draft-ietf-megaco-protocol-07.txt X-To: Scott Bradner , coya@ietf.org X-cc: Glen Freundlich To: MEGACO@STANDARDS.NORTELNETWORKS.COM Please forward draft-ietf-megaco-protocol-07.txt to the IESG for consideration as a Proposed Standard. Tom Taylor Advisor -- Emerging Carrier IP Standards E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 7 15:02:18 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23470 for ; Tue, 7 Mar 2000 15:02:17 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.88CCB020@standards.nortelnetworks.com>; Tue, 7 Mar 2000 14:58:01 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 78344 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 14:56:25 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4F2DB620@standards.nortelnetworks.com>; Tue, 7 Mar 2000 14:56:25 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 7 Mar 2000 14:00:17 -0600 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by zmers013; Tue, 7 Mar 2000 14:59:09 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 7 Mar 2000 14:59:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF886F.95D1605C" Message-ID: Date: Tue, 7 Mar 2000 14:58:58 -0500 Reply-To: Nancy-M Greene Sender: "Media Gateway Control (megaco)" From: Nancy-M Greene Subject: Re: the Internet-Draft 'Media Gateway Control' X-To: Hakime Kechouri 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_01BF886F.95D1605C Content-Type: text/plain The document is available at: http://www.ietf.org/internet-drafts/draft-ietf-megaco-reqs-10.txt as well as from the IETF Megaco WG web page at: http://www.ietf.org/html.charters/megaco-charter.html and from the Megaco WG ftp site at: ftp://standards.nortelnetworks.com/megaco/docs/latest As you say, it is an informational RFC, but we don't have the RFC number for it yet. Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > ---------- > From: Hakime Kechouri[SMTP:hkechouri@STARLINECOMMUNICATIONS.FR] > Sent: Monday, March 06, 2000 5:44 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: the Internet-Draft 'Media Gateway Control' > > <> > Dear Sirs > > Could you please send me the : > > Internet-Draft 'Media Gateway Control > Protocol Architecture and Requirements' > as an Informational RFC. This document is the product of the Media > Gateway > Control Working Group. The IESG contact persons are Scott Bradner and > Vern Paxson > ------_=_NextPart_001_01BF886F.95D1605C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: the Internet-Draft 'Media Gateway Control'

The document is = available at:
http://www.ietf.org/internet-drafts/draft-ietf-megaco-= reqs-10.txt

as well as from the = IETF Megaco WG web page at:
http://www.ietf.org/html.charters/megaco-charter.html<= /A>

and from the Megaco = WG ftp site at:
ftp://standards.nortelnetworks.com/megaco/docs/latest<= /A>

As you say, it is an = informational RFC, but we don't have the RFC number for it yet.

Nancy
-----------------------------------------------------------------= ---------
Nancy M. Greene
Internet & Service = Provider Networks, Nortel Networks
T:514-271-7221 = (internal:ESN853-1077) E:ngreene@nortelnetworks.com

    ----------
    From:   = Hakime = Kechouri[SMTP:hkechouri@STARLINECOMMUNICATIONS.FR]
    Sent:   = Monday, March 06, 2000 5:44 = AM
    To: =     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject: =        the Internet-Draft 'Media Gateway Control'

    <<File: = hkechouri.vcf>>
    Dear Sirs

    Could you please send me the :

    Internet-Draft 'Media Gateway = Control
    Protocol Architecture and = Requirements' <draft-ietf-megaco-reqs-10.txt>
    as an Informational RFC. This = document is the product of the Media
    Gateway
    Control Working Group.  The IESG = contact persons are Scott Bradner and
    Vern Paxson

------_=_NextPart_001_01BF886F.95D1605C-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 7 17:09:33 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01909 for ; Tue, 7 Mar 2000 17:09:32 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.526D4B90@standards.nortelnetworks.com>; Tue, 7 Mar 2000 17:05:21 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 78534 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 17:04:17 -0500 Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C6510760@standards.nortelnetworks.com>; Tue, 7 Mar 2000 16:54:17 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27958; Tue, 7 Mar 2000 16:58:01 -0500 (EST) Message-ID: <200003072158.QAA27958@ietf.org> Date: Tue, 7 Mar 2000 16:58:01 -0500 Reply-To: iesg@ietf.org Sender: "Media Gateway Control (megaco)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: The IESG Subject: Last Call: MEGACO Protocol to Proposed Standard To: MEGACO@STANDARDS.NORTELNETWORKS.COM The IESG has received a request from the Media Gateway Control Working Group to consider MEGACO Protocol as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by March 21, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-megaco-protocol-07.txt From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 7 17:53:36 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14715 for ; Tue, 7 Mar 2000 17:53:36 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7C9970F0@standards.nortelnetworks.com>; Tue, 7 Mar 2000 17:49:29 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 78621 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 17:48:00 -0500 Received: from muro.bes.es (195.53.182.2) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D6AC49C0@standards.nortelnetworks.com>; Tue, 7 Mar 2000 17:37:41 -0500 Received: from Mailhub by muro.bes.es id AA35200; Tue, 7 Mar 2000 23:35:53 +0100 Message-ID: <0003072235.AA35200@muro.bes.es> Date: Tue, 7 Mar 2000 23:35:53 +0100 Reply-To: khfnlcxbsb@HOTBOT.COM Sender: "Media Gateway Control (megaco)" From: khfnlcxbsb@HOTBOT.COM Subject: HOME TYPIST WANTED [rawwk] X-To: yltrztddfh@hotbot.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM HOME TYPIST WANTED Earn up to $50 an hour working from home processing simple legal forms for our company. Computer and printer required. No experience necessary. We are the National Association of Independent Paralegals. We have been processing simple divorce and bankruptcy forms since 1989. You do not have to have prior experience to work for us. We will train you and give you a diploma. For each case you type for us we will pay you $25. You do not have to be a fast typist, but you do need to be accurate with spelling, like the names of our customers. Other opportunties also available with our company, for information on our other work at home opportunities, please e-mail us at ---------------------------------------------- mailto:homeworker@chicagooffice.com?subject=moreinfo For Removal mailto:good_resource@usa.net?subject=out From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 7 17:59:36 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16988 for ; Tue, 7 Mar 2000 17:59:35 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5473C5C0@standards.nortelnetworks.com>; Tue, 7 Mar 2000 17:55:31 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 78663 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 17:54:01 -0500 Received: from muro.bes.es (195.53.182.2) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B8C2DBD0@standards.nortelnetworks.com>; Tue, 7 Mar 2000 17:44:00 -0500 Received: from Mailhub by muro.bes.es id AA41772; Tue, 7 Mar 2000 23:41:35 +0100 Message-ID: <0003072241.AA41772@muro.bes.es> Date: Tue, 7 Mar 2000 23:41:35 +0100 Reply-To: qskcqlgaqz@HOTBOT.COM Sender: "Media Gateway Control (megaco)" From: qskcqlgaqz@HOTBOT.COM Subject: HOME TYPIST WANTED [klebj] X-To: lqcksponxz@hotbot.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM HOME TYPIST WANTED Earn up to $50 an hour working from home processing simple legal forms for our company. Computer and printer required. No experience necessary. We are the National Association of Independent Paralegals. We have been processing simple divorce and bankruptcy forms since 1989. You do not have to have prior experience to work for us. We will train you and give you a diploma. For each case you type for us we will pay you $25. You do not have to be a fast typist, but you do need to be accurate with spelling, like the names of our customers. Other opportunties also available with our company, for information on our other work at home opportunities, please e-mail us at mailto:hometypers1@chicagooffice.com?subject=more ---------------------------------------------- Removal from further updates mailto:ipout@chicagooffice.com?subject=Remove mailto:homeworker@chicagooffice.com?subject=moreinfo For Removal mailto:good_resource@usa.net?subject=out From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 7 20:39:12 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03467 for ; Tue, 7 Mar 2000 20:39:10 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.969E64D0@standards.nortelnetworks.com>; Tue, 7 Mar 2000 20:34:51 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 78940 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 20:33:35 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.03861A40@standards.nortelnetworks.com>; Tue, 7 Mar 2000 20:23:35 -0500 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id RAA12730; Tue, 7 Mar 2000 17:24:44 -0800 (PST) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38C5AC96.235DC2E3@cisco.com> Date: Tue, 7 Mar 2000 20:27:51 -0500 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Subject: Comments on draft-ietf-megaco-protocol-07 X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Greetings Below you will find some comments on draft-ietf-megaco-protocol-07.txt. 1) 6.2.2, second last paragraph: It is still unclear to me what these "UNION" responses look like, at least if something besides the terminationID is returned. Please clarify. 2) 7.1.8, last bullet in second last bullet list: Shouldn't the MG also be prepared to receive media if Mode is loopback ? 3) 7.1.9, last sentence in the paragraph "When the MG receives a command with a new EventsDescriptor, one or more events may have been buffered in the EventBuffer i nthe MG. The value of EventBufferControl then determines how the MG treats such buffered events" should be clarified to indicate that the EventBufferControl referred to is the one for the new command. 4) 7.1.9, the paragraph "If the MG receives a command instructing it to set the value of EventBufferControl to Off, all events in the EventBuffer SHALL be discarded" should be removed as there seems to be no good reason for loosing those events. 5) 7.1.11, second paragraph: The granularity of the signal completion event defined in E.1.2 is too coarse. There is for example no way to be informed of just failures (which would seem generally desirable) without being more or less flooded by the other completion reasons as well (some of which are more questionable). One simple way out of this is to extend the definition of the signal completion event to include EventsDescriptorParameters where the TerminationMethod(s) of interest could be specified. Also, the term "notifyCompletion" is somewhat of a misnomer. 6) 7.1.11, last bullet list and sentence before that seems redundant with the KeepActive flag and could/should consequently be removed. 7) 7.1.14, last sentence in paragraph beginning with "The letter 'x' is used as a wildcard..." specifies that "As a consequence of the thrid timing rule above, inter-event timing while matching the dot symbol uses the short timer by default." is incorrect. The grammar may continue past the dot symbol implying the dot could only possibly produce a partial match which furthermore implies that the short timer may not be the right one to use. The sentence should simply be removed. 8) 7.1.14, next paragraph specifies that "A timer specified following a dot specifies inter-event timing for all events matching the dot as well as for subsequent events". It's unclear why the timer couldn't simply be put in front of the dot and thereby be consistent with digit map timers in general. In the absence of a compelling argument the sentence should simply be removed. 9) 7.1.14, numbered list, item 4: The second sentence and the last sentence seem to contradict each other. While absence of long-duration may prevent a match from occurring, existence of long-duration should not. Consequently, the second sentence is what should be modified. 10) 7.1.14, numbered list, item 5 specifies that "If exactly one candidate remains, a completion event is generated indicating an unambiguous match". This seems to imply that even a partial match (as long as there is only one) will result in a digit map completion event, which of course is incorrect. 11) 7.1.14, numbered list, item 5: It is entirely unclear why an event triggering a partial match is not reported as part of the matched string. In the absence of a compelling argument, the triggering event should be included in the string as it otherwise may be processed twice, which is hardly what the user had in mind. 12) 7.1.14, second last paragraph states that "Regardles of whether a digit map is activated, this form of event specification will cause the individual events to be reported to the MGC as they are detected". Some clarification is requested here. 13) 7.1.17, first paragraph states that "Used with the AuditValue command, the ObservedEventsDescriptor returns events in the event buffer which have not been Notified". It should be clarified whether that includes events that are being matched against a digit map or not. 14) 7.2.3, bullet list, first item states that [property values revert to] "the default value, if specified for the property and not overriden by provisioning". The provisioning part seems to contradict Section 6.2.4 and furthermore be redundant with the following bullet. Consequently, the provisioning part in the first bullet should simply be deleted. 15) 7.2.5, fourth paragraph states that "Digitmap requested in an AuditValue command with TerminationID ALL returns all DigitMaps in the gateway". Since digitmaps defined on specific terminations "shadow" digit maps defined on the root termination, it would seem that digit maps defined on root should be excluded here (unless the reporting starts including the termination the digit map is defined on which seems to be a more substantial change). 16) 7.2.8, Restart: As I have stated before, it is a mistake that the gateway is not defined to be in a clean and well-defined state when "Restart" is issued. Consequently, I suggest that the sentence "the Terminations are assumed to now not be associated with any Context" is put back in this defintion again. 17) 7.2.8, paragraph beginning with "A ServiceChange Command specifying..." states that "Acknowledgement of the ServiceChange Command completes the registration process", however this seems to conflict with the procedures specified later, where it is in fact determined by the MGCId returned (if it's the same, registration completed). The sentence should be modified accordingly. 18) 7.2.9, last paragraph specifies that "If a MG receives an action which contains both a request to audit context attributes and a request to manipulate those attributes, the response SHALL include the values of the attributes after processing the manipulation request". While the above behavior makes sense for a *command*, it does not for a action and furthermore it is in conflict with the general command processing order defined in Section 8. The sentence should be modified accordingly 19) 8: It is still unclear whether commands are atomic or not. At the very least this needs to be clarified as well as what effect a failed command may have on a gateway/termination. 20a) 11.2, first paragraph, last sentence: Editorial mistake (cf. 11.3) ? Sentence should be brought back to "If the MG is unable to establish a control relationship with any MGC, it shall wait a random amount of time as described in Section 9.2 and then start contacting its primary, and if necessary, its secondary MGCs again" 20b) 12.1.4, specifies that "Signals that would be played with SignalType BR should have a default duration". The same should be specified for signals with SignalType TO. 21) D.1, first paragraph, last sentence specifies that "Responses must be sent to the address and port from which the corresponding commands were sent except if the response to a handoff or failover, in which case the procedures of 11.5 apply". While this may be reasonable for clustered systems, it does not seem reasonable for handoff between non-clustered systems. To enable reliable delivery of this message, the response should still be sent to the source of the request, but otherwise the procedures of 11.5 applies. 22) D.1.1, second paragraph, last line: The reference to Section 8.2.3 should be replace with a reference to Section D.1.4, as this section describes UDP specific requirements, where as 8.2.3 is transport independent and consequently has looser specification language ("may"). 23) D.1.4, first paragraph The sentence "They should send this response if they receive a repetition of a transaction that is still being executed" has been deleted. The sentence should be added back in again. 24) D.1.4, last paragraph specifies that "Upon receipt of of a final response, an immediate confirmation shall be sent, and normal repetition timers shall be used thereafter", however it is not specified how the entity determines whether the final response needs to be confirmed immediately or not (consider the case where the pending was lost). A specification for this needs to be added. 25) D.1.5, last paragraph specifies that "When the MG establishes a new control association, it can retransmit to the new MGC. Alternatively, a MG may use a ServiceChange with ServiceChangeMethod equal to disconnected to inform the new MGC that the MG lost one or more transaction". In order to prevent duplicate transactions, it must be required that transactions cannot be retransmitted T-MAX time after their initial transmission. Consequently, a disconnected ServiceChange *must* be issued in such cases. 26), E.1.2, Signal Completion: See issue 5 27), E.9.2, onhook/offhook: The text specifies that if "onhook/ofhook" is requested while the phone is already onhook/offhook, an onhook/offhook event will be generated. This behavior does not handle glare properly and may consequently result in two onhook/offhook events being generated for a single onhook/offhook transition. As part of glare handling, it is furthermore important to enable a coupling between an expected hook-state and the application of signals. One way of accomplishing the above would simply be to define a couple of event parameters for onhook and offhook: A. No expected hook-state, just report next transition. B. Expected hook-state, report if hook-state differs (the current text). C. Expected hook-state must be met or command will fail. 28) E.10.2, specifies that "If the return tone is detected before the signal times out, the cmp event shall be generated with the value...". In practice, there may be a little more to the test (e.g. successful removal of the tone again) so the success criteria should probably be a little more general and simply refer to a successful test or not. Regards Flemming -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 7 21:58:13 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28823 for ; Tue, 7 Mar 2000 21:58:12 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A5457540@standards.nortelnetworks.com>; Tue, 7 Mar 2000 21:54:00 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 79062 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 21:53:16 -0500 Received: from mailboy.huawei.com.cn (202.96.135.134) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.22D1B9D0@standards.nortelnetworks.com>; Tue, 7 Mar 2000 21:43:12 -0500 Received: from w14798 ([10.105.30.250]) by mailboy.huawei.com.cn (Netscape Mail Server v2.02) with ESMTP id AAA3812 for ; Wed, 8 Mar 2000 10:40:48 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008D_01BF88EB.4ED77B60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Message-ID: <009001bf88a8$410827c0$fa1e690a@w14798.huawei.com.cn> Date: Wed, 8 Mar 2000 10:44:41 +0800 Reply-To: Wu Yongji Sender: "Media Gateway Control (megaco)" From: Wu Yongji Subject: About hairpin connection To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_008D_01BF88EB.4ED77B60 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Hi all, I've known that a large MG can be partitioned into multiple virtual = logical MGs according to H.248 protocol & The requiements 10, each of = which is controlled by separated MGCs. =20 If a large physical access gateway is partitioned into two virtual = gateways G1 and G1 controlled by separated MGCs, would you mind an = example about how to establish a call between two subscribers S1 and S2 = attached to G1 and G2. Regards Wu Yongji ------=_NextPart_000_008D_01BF88EB.4ED77B60 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable ------=_NextPart_000_008D_01BF88EB.4ED77B60-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 7 23:31:25 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23337 for ; Tue, 7 Mar 2000 23:31:24 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A81C01F0@standards.nortelnetworks.com>; Tue, 7 Mar 2000 23:27:08 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 79184 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 7 Mar 2000 23:25:32 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6E69F520@standards.nortelnetworks.com>; Tue, 7 Mar 2000 23:25:31 -0500 Received: from zmers013 by smtprch1.nortel.com; Tue, 7 Mar 2000 22:29:19 -0600 Received: from zrchb213.us.nortel.com (actually zrchb213) by zmers013; Tue, 7 Mar 2000 23:25:49 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 7 Mar 2000 22:25:44 -0600 X-Mailer: Internet Mail Service (5.5.2650.21) Message-ID: Date: Tue, 7 Mar 2000 22:25:42 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Questions on MEGACO/H.248 v16 - More X-To: Xiuping Qiu To: MEGACO@STANDARDS.NORTELNETWORKS.COM Thank you for the questions. I do wonder if we have to write a new document collecting all the explanations. Maybe a list of frequently asked questions (FAQ). My responses below. > -----Original Message----- > From: Xiuping Qiu [SMTP:qiuxiuping@SZ.HUAWEI.COM.CN] > Sent: Tuesday, March 07, 2000 7:27 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Questions on MEGACO/H.248 v16 - More > > Hi, all > > Thanks for those who reponses me. > Also thanks for you who reads my questions. > > 1. When ReserveValue and ReserveGroup are true , how the parameters > of Value and Group are matched? [[TomT]] I'm not clear what you mean by "matched". Do you mean matching of alternatives selected in Local against alternatives selected in Remote? > And if ReserveValue and ReserveGroup are true, will it return large > numbers of info? For example,if ReserveValue is true,and there is a > "m=audio $ RTP/AVP 0 " line in Local Descriptor,then should MG return > all possible port numbers to MGC? [[TomT]] Remember to start with that the MG is reserving resources. These resources will therefore be unavailable to serve other calls until the MGC releases them by being more selective in its requests. In our interpretation of the different syntactic possibilities and how the MG should react to them, we should be looking for principles that lead to reasonable behaviour. Now, what are the syntactic possibilities for any parameter? In text-encoded terms, they are: (a) "$" also known as CHOOSE. The most reasonable interpretation, particularly in the light of your example, is that "$" always asks the MG to choose a single value for the parameter concerned. Again, for your particular example, if there are multiple session descriptions and ReserveGroup is TRUE, it would make sense for the MG to reserve the same port for audio in every session description it returns, since the assumption is that only one of these session descriptions will be chosen in the end. (b) A comma-separated list of values enclosed within brackets. Here the assumption should be that the values are listed in descending order of preference, and subject to that ordering the MG should reserve resources to cover as many of the values as possible. ("Cover" means that it is prepared for the MGC or the far end to select that value to be the one actually used.) We have a problem here: SDP does not support the same syntax for a list of alternatives, so how does the MG provide a response which is properly-formed SDP? The brute force answer is to use SDP mechanisms for the purpose where they exist, and otherwise spell out alternatives in multiple session descriptions. The problem with the latter is that the required number of session descriptions will grow exponentially with the number of parameters for which alternatives are supplied. Perhaps someone can think of a more clever answer. (c) A bracket-enclosed range of values. It is harder here to think that the ordering implicit in the range represents any sort of order of preference. Instead, I propose that the intent is that the MG be prepared to support as many values as possible within that range. If it weren't for the rule that the MG must respond with proper SDP syntax, the MG would respond either with a range which may be a subset of the original or with a list of individual values selected from the range. The brute force means of conforming to SDP syntax is even more difficult than in the previous case. Help! (d) An inequality constraint. The same logic that applies to ranges also applies to inequalities. > 2. In 7.1.8 Local and Remote Descriptors > > (a) An unspecified Local or Remote descriptor is considered to be > a missing mandatory parameter. It requires the MG to use whatever > was last specified for that descriptor. It is possible that there was > no previously-specified value, in which case the descriptor concerned > is ignored in further processing of the command. > > It seems that the above conflicts with the Example of Appendix A. [[TomT]] Which step? > 3. ?If the Mode property of the LocalControl descriptor is RecvOnly or > SendRecv, the MG must be prepared to receive media encoded according to > any of the alternatives included in its response to the MGC. ? > > Question :What exact alternative does MG use to receive media? e.g. When > the peer MG has sent media encoded in one of the alternatives,how does the > prepared MG know what type is the encoding? [[TomT]] It's shown by the payload type in the RTP header. > 4. E.6.2 Events > > Original: > Termination Method > ParameterID: Meth (0x0003) > Type: enumeration > Possible values: > "UM" (0x0001) Unambiguous match > "PM" (0x0002) Partial match, completion by timer expiry or > unmatched event > "FM" (0x0003) Full match, completion by timer expiry or unmatched > event > Description: indicates the reason for generation of the event. See the > procedures in section . > > Question : > While dialing the MG detects the onhook events, then will it happen the > DigitMapCompletion event? If it happens, what the kind of Termination > Method is ? > And, Which event happens first ? Onhook or DigitMap Completion? [[TomT]] The usual case would be that the EventsDescriptor changes as a result of on-hook. If this doesn't happen, DigitMapCompletion will come about as a result of timer expiry, and thus will generally follow some time after the on-hook. > 5. 7.1.9 Events Descriptor > > Question: > In Case 1, EventBufferControl = LockStep ,EventBuffer is empty,Will > EventDescriptor > and EventBufferDescriptor both work ? If they both work, suppose one > event exists > in both Descriptors, Then how to deal with it ? [[TomT]] Events are never screened against both EventDescriptor and EventBufferDescriptor at the same time. In the case you give, the next arriving event will be screened against the EventDescriptor only, reported if it is matched, and discarded if it is not matched. If it is matched, subsequent events will be screened against the EventBufferDescriptor and placed in the EventBuffer until a new EventDescriptor is activated. > 6. Question: > > Before replaced by a new one, can an EventDescriptor be used to detect > specified events > more than once? I.e. One EventDescriptor contains an EventID dt , after > detected once, > if event dt happened again , and the EventDescriptor is not replaced. Will > the MG Notify > the event? [[TomT]] This will happen if EventBufferControl = "off". > Thanks, > Xiuping Qiu > _______________________________________________ > > Xiuping Qiu > Huawei Technologies Co., Ltd. > Mail to: qiuxiuping@sz.huawei.com.cn > Tel : +86 755 6544482 > Visit : http://www.huawei.com.cn > _______________________________________________ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 8 04:51:48 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03435 for ; Wed, 8 Mar 2000 04:51:48 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.65A06140@standards.nortelnetworks.com>; Wed, 8 Mar 2000 4:47:24 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 79374 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Mar 2000 04:46:03 -0500 Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.35696490@standards.nortelnetworks.com>; Wed, 8 Mar 2000 4:46:03 -0500 Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id KAA13991 for ; Wed, 8 Mar 2000 10:49:53 +0100 (MET) Received: from uabs28 (uabs28i3 [134.138.201.3]) by ms.uab.ericsson.se (8.9.3/8.9.3/uab-2.21) with ESMTP id KAA24093 for ; Wed, 8 Mar 2000 10:49:52 +0100 (MET) Received: from uab.ericsson.se by uabs28 (8.8.8+Sun/client-1.3uab2) id KAA24430; Wed, 8 Mar 2000 10:49:51 +0100 (MET) X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------3D0AC01595E5595E34088554" Message-ID: <38C6223F.4F0DD982@uab.ericsson.se> Date: Wed, 8 Mar 2000 10:49:51 +0100 Reply-To: Alf Heidermark Sender: "Media Gateway Control (megaco)" From: Alf Heidermark Organization: Ericsson Utvecklings AB Subject: Cold start procedure To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------3D0AC01595E5595E34088554 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello How will an MG react if it does not get a ServiceChangeMGCid in the Transaction Accept, as a reply to a ServiceChange with ROOT termination and method set to restart. --------------3D0AC01595E5595E34088554 Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Description: Card for Alf Heidermark Content-Disposition: attachment; filename="vcard.vcf" Content-Transfer-Encoding: 7bit begin: vcard fn: Alf Heidermark n: Heidermark;Alf org: Ericsson Core Network product email;internet: Alf.Heidermark@uab.ericsson.se note;quoted-printable:Telphone number +4687273894=0D=0A= Mobile: +46703997883=0D=0A= Address: Armborstv=E4gen 14=0D=0A= =C4lvsj=F6 x-mozilla-cpt: ;0 x-mozilla-html: FALSE version: 2.1 end: vcard --------------3D0AC01595E5595E34088554-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 8 05:13:39 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10056 for ; Wed, 8 Mar 2000 05:13:39 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.79E5DD80@standards.nortelnetworks.com>; Wed, 8 Mar 2000 5:09:27 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 79407 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Mar 2000 05:07:43 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3BC293E0@standards.nortelnetworks.com>; Wed, 8 Mar 2000 5:07:42 -0500 Received: from chsharp-tecra (tokyo-dhcp096.cisco.com [144.254.168.224]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id CAA25564; Wed, 8 Mar 2000 02:11:30 -0800 (PST) X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.2.2.20000308185807.00cd2410@dogwood.cisco.com> Date: Wed, 8 Mar 2000 19:04:14 -0800 Reply-To: Chip Sharp Sender: "Media Gateway Control (megaco)" From: Chip Sharp Subject: Re: Event handling questions X-To: Flemming Andreasen To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <38C51A06.DAE1FAFE@cisco.com> At 10:02 AM 3/7/00 -0500, Flemming Andreasen wrote: >A couple of questions on the event handling (7.1.9): > >1. It is specified that "When the MG receives a command with a new >EventsDescriptor, one or more events may have been buffered in the >EventBuffer in the MG. The value of EventBufferControl then determines >how the MG treats such buffered events." > >I assume that the "the value of EventBufferControl" refers to the value >in the new command (if supplied), not the old, correct ? There is text in the spec somewhere that describes the order of operation. I don't remember where. If that text says to process EventBufferControl before the new EventsDescriptor, then the new value of EventBufferControl is used. Otherwise, the old value is used. >2. It is specified that "If the MG receives a command instructing it to >set the value of EventBufferControl to Off, all events in the >EventBuffer SHALL be discarded." > >This seems rather strange to me as you will be dropping events for no >apparent reason. Can somebody please explain the rationale behind this ? I can't. >Thanks > > Flemming > >-- >Flemming Andreasen >Cisco Systems Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. -------------------------------------------------- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 8 07:41:56 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21421 for ; Wed, 8 Mar 2000 07:41:55 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2E4269B0@standards.nortelnetworks.com>; Wed, 8 Mar 2000 7:37:39 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 79562 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Mar 2000 07:36:26 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9C9DFA70@standards.nortelnetworks.com>; Wed, 8 Mar 2000 7:26:25 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id HAA08223; Wed, 8 Mar 2000 07:30:10 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id HAA29514; Wed, 8 Mar 2000 07:30:12 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Wed, 8 Mar 2000 07:26:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF32EB28@whq-msgusr-02.fore.com> Date: Tue, 7 Mar 2000 22:36:24 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Event handling questions X-To: Flemming Andreasen To: MEGACO@STANDARDS.NORTELNETWORKS.COM It seems to me that a particular MGC will either keep EventBufferControl on or off. There has to be a way to clear the buffer. Turning it from on to off seems to be an appropriate way to do that. Brian > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Tuesday, March 07, 2000 11:04 AM > To: MEGACO@standards.nortelnetworks.com > Subject: Re: Event handling questions > > > Tom-PT Taylor wrote: > > > > > > > Replies below. > > > > -----Original Message----- > > From: Flemming Andreasen [SMTP:fandreas@CISCO.COM] > > Sent: Tuesday, March 07, 2000 10:03 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Event handling questions > > > > A couple of questions on the event handling (7.1.9): > > > > 1. It is specified that "When the MG receives a command with a > > new > > EventsDescriptor, one or more events may have been buffered in > > the > > EventBuffer in the MG. The value of EventBufferControl then > > determines > > how the MG treats such buffered events." > > > > I assume that the "the value of EventBufferControl" > refers to the > > value > > in the new command (if supplied), not the old, correct ? > > [[TomT]] > > That is correct. > > > > 2. It is specified that "If the MG receives a command > instructing > > it to > > set the value of EventBufferControl to Off, all events in the > > EventBuffer SHALL be discarded." > > > > This seems rather strange to me as you will be dropping events > > for no > > apparent reason. Can somebody please explain the > rationale behind > > this ? > > > > [[TomT]] If the MGC turns EventBufferControl off, it > must have a > > reason for doing so. The same reason presumably extends to the > > treatment of events already in the buffer. > > > I don't follow. How does that justify throwing away the > events that were > already buffered ? The only thing you are changing is the way > you report > events. For example consider the case where the set of events to be > detected in the two commands are exactly the same but the > EventBufferControl differs. > > > > > > > Thanks > > > > Flemming > > > > -- > > Flemming Andreasen > > Cisco Systems > > > -- > Flemming Andreasen > Cisco Systems > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 8 08:06:59 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28832 for ; Wed, 8 Mar 2000 08:06:59 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.ADDD9ED0@standards.nortelnetworks.com>; Wed, 8 Mar 2000 8:02:42 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 79600 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Mar 2000 08:01:32 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1E7C8FE0@standards.nortelnetworks.com>; Wed, 8 Mar 2000 7:51:32 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id HAA09885; Wed, 8 Mar 2000 07:55:21 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id HAA02800; Wed, 8 Mar 2000 07:55:23 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Wed, 8 Mar 2000 07:51:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF208A85@whq-msgusr-02.fore.com> Date: Wed, 8 Mar 2000 07:55:01 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Cold start procedure X-To: Alf Heidermark To: MEGACO@STANDARDS.NORTELNETWORKS.COM It will use the default address/port it contacted the MGC on in the first place. Brian > -----Original Message----- > From: Alf Heidermark [mailto:Alf.Heidermark@UAB.ERICSSON.SE] > Sent: Wednesday, March 08, 2000 4:50 AM > To: MEGACO@standards.nortelnetworks.com > Subject: Cold start procedure > > > Hello > > How will an MG react if it does not get a ServiceChangeMGCid in the > Transaction Accept, as a reply to a ServiceChange with ROOT > termination > and method set to restart. > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 8 10:46:46 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25611 for ; Wed, 8 Mar 2000 10:46:44 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F8903B70@standards.nortelnetworks.com>; Wed, 8 Mar 2000 10:42:16 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 79907 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Mar 2000 10:40:49 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5E6184B0@standards.nortelnetworks.com>; Wed, 8 Mar 2000 10:30:48 -0500 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id HAA02503; Wed, 8 Mar 2000 07:34:37 -0800 (PST) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF32EB28@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38C673A5.6001A590@cisco.com> Date: Wed, 8 Mar 2000 10:37:10 -0500 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Subject: Re: Event handling questions X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit "Rosen, Brian" wrote: > It seems to me that a particular MGC will either keep EventBufferControl on > or off. > There has to be a way to clear the buffer. Turning it from on to off seems > to be > an appropriate way to do that. You can argue either way, which is why I've always argued this should have been two instead of one parameter. In the absence of that the question then becomes whether you should always drop the events or not. The safe approach which satisfies all scenarios is not to drop them which actually has the effect of clearing the buffer as well since the MG is fully allowed to empty the eventbuffer in a single Notify message when EventBufferControl is off. Consequently I say they should not be dropped. > > > Brian > > > -----Original Message----- > > From: Flemming Andreasen [mailto:fandreas@cisco.com] > > Sent: Tuesday, March 07, 2000 11:04 AM > > To: MEGACO@standards.nortelnetworks.com > > Subject: Re: Event handling questions > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > Replies below. > > > > > > -----Original Message----- > > > From: Flemming Andreasen [SMTP:fandreas@CISCO.COM] > > > Sent: Tuesday, March 07, 2000 10:03 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Event handling questions > > > > > > A couple of questions on the event handling (7.1.9): > > > > > > 1. It is specified that "When the MG receives a command with a > > > new > > > EventsDescriptor, one or more events may have been buffered in > > > the > > > EventBuffer in the MG. The value of EventBufferControl then > > > determines > > > how the MG treats such buffered events." > > > > > > I assume that the "the value of EventBufferControl" > > refers to the > > > value > > > in the new command (if supplied), not the old, correct ? > > > [[TomT]] > > > That is correct. > > > > > > 2. It is specified that "If the MG receives a command > > instructing > > > it to > > > set the value of EventBufferControl to Off, all events in the > > > EventBuffer SHALL be discarded." > > > > > > This seems rather strange to me as you will be dropping events > > > for no > > > apparent reason. Can somebody please explain the > > rationale behind > > > this ? > > > > > > [[TomT]] If the MGC turns EventBufferControl off, it > > must have a > > > reason for doing so. The same reason presumably extends to the > > > treatment of events already in the buffer. > > > > > I don't follow. How does that justify throwing away the > > events that were > > already buffered ? The only thing you are changing is the way > > you report > > events. For example consider the case where the set of events to be > > detected in the two commands are exactly the same but the > > EventBufferControl differs. > > > > > > > > > > > > Thanks > > > > > > Flemming > > > > > > -- > > > Flemming Andreasen > > > Cisco Systems > > > > > -- > > Flemming Andreasen > > Cisco Systems > > -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 8 14:17:07 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04715 for ; Wed, 8 Mar 2000 14:17:06 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3D553040@standards.nortelnetworks.com>; Wed, 8 Mar 2000 14:11:47 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 80295 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Mar 2000 14:10:54 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1DFE6C20@standards.nortelnetworks.com>; Wed, 8 Mar 2000 14:10:54 -0500 Received: from zmers013 by smtprch1.nortel.com; Wed, 8 Mar 2000 13:14:43 -0600 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by zmers013; Wed, 8 Mar 2000 14:14:09 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 8 Mar 2000 14:14:09 -0500 X-Mailer: Internet Mail Service (5.5.2650.21) Message-ID: Date: Wed, 8 Mar 2000 14:14:02 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Next Steps X-cc: Glen Freundlich , Brian Rosen , "John Segers (E-mail)" To: MEGACO@STANDARDS.NORTELNETWORKS.COM I think the outstanding WG comments on the protocol document are going to require some discussion before we can get to the point of issuing a set of officially accepted errata. Hence any instructions I issued to our editors to the contrary should go on hold. Keith Drage's comments seem eminently reasonable, but since they are editorial in nature, I think it will be up to Glen Freundlich and John Segers to resolve -- I don't think Megaco has anything to contribute here. I'm off to Australia. I'll be back in E-mail contact before the deadline for I-D submission on Friday, if something urgent comes up. Tom Taylor Advisor -- Emerging Carrier IP Standards E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 8 16:33:30 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14842 for ; Wed, 8 Mar 2000 16:33:29 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6E0CD400@standards.nortelnetworks.com>; Wed, 8 Mar 2000 16:29:09 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 80576 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Mar 2000 16:28:10 -0500 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4AC32AD0@standards.nortelnetworks.com>; Wed, 8 Mar 2000 16:28:10 -0500 Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id XAA23251 for ; Wed, 8 Mar 2000 23:32:01 +0200 (EET) Received: from loki.research.nokia.com (loki.research.nokia.com [172.21.33.76]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id XAA24133 for ; Wed, 8 Mar 2000 23:32:00 +0200 (EET) Received: from rama.research.nokia.com (IDENT:root@rama.research.nokia.com [172.21.40.44]) by loki.research.nokia.com (8.9.3/8.9.3) with ESMTP id XAA23853 for ; Wed, 8 Mar 2000 23:32:00 +0200 (EET) Received: (from ppessi@localhost) by rama.research.nokia.com (8.9.3/8.9.1) id XAA30966; Wed, 8 Mar 2000 23:32:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i References: X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Message-ID: <14534.50895.827586.981919@rama.research.nokia.com> Date: Wed, 8 Mar 2000 23:31:59 +0200 Reply-To: Pekka.Pessi@nokia.com Sender: "Media Gateway Control (megaco)" From: Pekka Pessi Subject: Summary Of Errors Found In Megaco/H.248 Protocol Document To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Content-Transfer-Encoding: 7bit Tom-PT Taylor writes: >Wednesday is the end of the Last Call period for >draft-ietf-megaco-protocol-07.txt. After a very quiet start, we do seem to >have a small list of issues which need rectification. This is a summary for >your review. Please pass any other issues you have found to the list ASAP. A short glance to the document: Interim AH scheme described in 10.2 is still the version from the January draft. As noody seems to be very interested in Interim AH scheme, I propose it will be dropped off from the spec. Pekka Pessi From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 8 23:28:08 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13590 for ; Wed, 8 Mar 2000 23:28:07 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5B954D40@standards.nortelnetworks.com>; Wed, 8 Mar 2000 23:23:49 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 81114 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 8 Mar 2000 23:22:43 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CEAE8D20@standards.nortelnetworks.com>; Wed, 8 Mar 2000 23:12:43 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id XAA23177; Wed, 8 Mar 2000 23:16:30 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id XAA07861; Wed, 8 Mar 2000 23:16:31 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Wed, 8 Mar 2000 23:12:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF208A8A@whq-msgusr-02.fore.com> Date: Wed, 8 Mar 2000 23:16:08 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Event handling questions X-To: Flemming Andreasen To: MEGACO@STANDARDS.NORTELNETWORKS.COM I think there is no way an MGC is going to switch event buffering on and off depending on what happens - either it will be set on and left, or set off and left. If it is on, there needs to be a way to clear the buffer. If it is off, you never have the problem. I'd be okay in separating the controls (having two separate properties), but at this late date, it may not be worth it. I'll let Tom pass judgment on that. Brian > -----Original Message----- > From: Flemming Andreasen [mailto:fandreas@cisco.com] > Sent: Wednesday, March 08, 2000 10:37 AM > To: Rosen, Brian > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Event handling questions > > > > > "Rosen, Brian" wrote: > > > It seems to me that a particular MGC will either keep > EventBufferControl on > > or off. > > There has to be a way to clear the buffer. Turning it from > on to off seems > > to be > > an appropriate way to do that. > > You can argue either way, which is why I've always argued > this should have been > two instead of one parameter. In the absence of that the > question then becomes > whether you should always drop the events or not. The safe > approach which > satisfies all scenarios is not to drop them which actually > has the effect of > clearing the buffer as well since the MG is fully allowed to empty the > eventbuffer in a single Notify message when EventBufferControl is off. > Consequently I say they should not be dropped. > > > > > > > > Brian > > > > > -----Original Message----- > > > From: Flemming Andreasen [mailto:fandreas@cisco.com] > > > Sent: Tuesday, March 07, 2000 11:04 AM > > > To: MEGACO@standards.nortelnetworks.com > > > Subject: Re: Event handling questions > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > > > > Replies below. > > > > > > > > -----Original Message----- > > > > From: Flemming Andreasen [SMTP:fandreas@CISCO.COM] > > > > Sent: Tuesday, March 07, 2000 10:03 AM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Event handling questions > > > > > > > > A couple of questions on the event handling (7.1.9): > > > > > > > > 1. It is specified that "When the MG receives a > command with a > > > > new > > > > EventsDescriptor, one or more events may have been > buffered in > > > > the > > > > EventBuffer in the MG. The value of EventBufferControl then > > > > determines > > > > how the MG treats such buffered events." > > > > > > > > I assume that the "the value of EventBufferControl" > > > refers to the > > > > value > > > > in the new command (if supplied), not the old, correct ? > > > > [[TomT]] > > > > That is correct. > > > > > > > > 2. It is specified that "If the MG receives a command > > > instructing > > > > it to > > > > set the value of EventBufferControl to Off, all > events in the > > > > EventBuffer SHALL be discarded." > > > > > > > > This seems rather strange to me as you will be > dropping events > > > > for no > > > > apparent reason. Can somebody please explain the > > > rationale behind > > > > this ? > > > > > > > > [[TomT]] If the MGC turns EventBufferControl off, it > > > must have a > > > > reason for doing so. The same reason presumably > extends to the > > > > treatment of events already in the buffer. > > > > > > > I don't follow. How does that justify throwing away the > > > events that were > > > already buffered ? The only thing you are changing is the way > > > you report > > > events. For example consider the case where the set of > events to be > > > detected in the two commands are exactly the same but the > > > EventBufferControl differs. > > > > > > > > > > > > > > > > > Thanks > > > > > > > > Flemming > > > > > > > > -- > > > > Flemming Andreasen > > > > Cisco Systems > > > > > > > -- > > > Flemming Andreasen > > > Cisco Systems > > > > > -- > Flemming Andreasen > Cisco Systems > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 9 05:30:35 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07110 for ; Thu, 9 Mar 2000 05:30:35 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F8486EB0@standards.nortelnetworks.com>; Thu, 9 Mar 2000 5:26:06 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 81318 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Mar 2000 05:24:13 -0500 Received: from auemail2.firewall.lucent.com (192.11.223.163) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B452F8B0@standards.nortelnetworks.com>; Thu, 9 Mar 2000 5:24:12 -0500 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 FAA09307 for ; Thu, 9 Mar 2000 05:28:06 -0500 (EST) 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 FAA09282 for ; Thu, 9 Mar 2000 05:28:05 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA09744; Thu, 9 Mar 2000 11:28:04 +0100 (MET) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA09635; Thu, 9 Mar 2000 11:27:52 +0100 (MET) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Original-CC: MEGACO@standards.nortelnetworks.com References: <4FBEA8857476D311A03300204840E1CF32EB28@whq-msgusr-02.fore.com> <38C673A5.6001A590@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38C77CA7.1F649403@lucent.com> Date: Thu, 9 Mar 2000 11:27:51 +0100 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: Event handling questions X-To: Flemming Andreasen To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Flemming, You're right in saying that it is not forbidden to have all events in the buffer notified in one go (although there is no text that says when one would include multiple events in one Notify). Also, it is allowed for the MGC to send one message that audits the observed events descriptor (so it gets all events currently in the buffer), and clear the buffer by setting eventbuffercontrol to Off. So it seems to me that you can do what you want without changing the protocol. And you have a means for the MGC to reduce the traffic if it really thinks that it doesn't need to see the buffered events. Cheers, John Flemming Andreasen wrote: > > "Rosen, Brian" wrote: > > > It seems to me that a particular MGC will either keep EventBufferControl on > > or off. > > There has to be a way to clear the buffer. Turning it from on to off seems > > to be > > an appropriate way to do that. > > You can argue either way, which is why I've always argued this should have been > two instead of one parameter. In the absence of that the question then becomes > whether you should always drop the events or not. The safe approach which > satisfies all scenarios is not to drop them which actually has the effect of > clearing the buffer as well since the MG is fully allowed to empty the > eventbuffer in a single Notify message when EventBufferControl is off. > Consequently I say they should not be dropped. > > > > > > > Brian > > > > > -----Original Message----- > > > From: Flemming Andreasen [mailto:fandreas@cisco.com] > > > Sent: Tuesday, March 07, 2000 11:04 AM > > > To: MEGACO@standards.nortelnetworks.com > > > Subject: Re: Event handling questions > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > > > > Replies below. > > > > > > > > -----Original Message----- > > > > From: Flemming Andreasen [SMTP:fandreas@CISCO.COM] > > > > Sent: Tuesday, March 07, 2000 10:03 AM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Event handling questions > > > > > > > > A couple of questions on the event handling (7.1.9): > > > > > > > > 1. It is specified that "When the MG receives a command with a > > > > new > > > > EventsDescriptor, one or more events may have been buffered in > > > > the > > > > EventBuffer in the MG. The value of EventBufferControl then > > > > determines > > > > how the MG treats such buffered events." > > > > > > > > I assume that the "the value of EventBufferControl" > > > refers to the > > > > value > > > > in the new command (if supplied), not the old, correct ? > > > > [[TomT]] > > > > That is correct. > > > > > > > > 2. It is specified that "If the MG receives a command > > > instructing > > > > it to > > > > set the value of EventBufferControl to Off, all events in the > > > > EventBuffer SHALL be discarded." > > > > > > > > This seems rather strange to me as you will be dropping events > > > > for no > > > > apparent reason. Can somebody please explain the > > > rationale behind > > > > this ? > > > > > > > > [[TomT]] If the MGC turns EventBufferControl off, it > > > must have a > > > > reason for doing so. The same reason presumably extends to the > > > > treatment of events already in the buffer. > > > > > > > I don't follow. How does that justify throwing away the > > > events that were > > > already buffered ? The only thing you are changing is the way > > > you report > > > events. For example consider the case where the set of events to be > > > detected in the two commands are exactly the same but the > > > EventBufferControl differs. > > > > > > > > > > > > > > > > > Thanks > > > > > > > > Flemming > > > > > > > > -- > > > > Flemming Andreasen > > > > Cisco Systems > > > > > > > -- > > > Flemming Andreasen > > > Cisco Systems > > > > > -- > Flemming Andreasen > Cisco Systems -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 9 06:42:59 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29439 for ; Thu, 9 Mar 2000 06:42:59 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CA765880@standards.nortelnetworks.com>; Thu, 9 Mar 2000 6:36:24 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 81479 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Mar 2000 06:35:58 -0500 Received: from ietf.org (132.151.1.176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.54F6F570@standards.nortelnetworks.com>; Thu, 9 Mar 2000 6:25:58 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25127; Thu, 9 Mar 2000 06:29:51 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200003091129.GAA25127@ietf.org> Date: Thu, 9 Mar 2000 06:29:51 -0500 Reply-To: Internet-Drafts@ietf.org Sender: "Media Gateway Control (megaco)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-megaco-naspkg-00.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) : M. Kalla, Z. Bilalis Filename : draft-ietf-megaco-naspkg-00.txt Pages : 4 Date : 08-Mar-00 This document is work in progress and defines a NAS Package for the Megaco/H.248 protocol. It is intended to satisfy the requirements in section 11.2.5 of the Megaco/H.248 requirements document [5]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-megaco-naspkg-00.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-00.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-00.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: <20000308131928.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-megaco-naspkg-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-megaco-naspkg-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000308131928.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 9 07:15:55 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09417 for ; Thu, 9 Mar 2000 07:15:54 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B2F4CA70@standards.nortelnetworks.com>; Thu, 9 Mar 2000 7:11:33 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 81650 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Mar 2000 07:09:47 -0500 Received: from relay.mail.pipex.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.739927E0@standards.nortelnetworks.com>; Thu, 9 Mar 2000 7:09:46 -0500 Received: (qmail 13035 invoked from network); 9 Mar 2000 12:13:36 -0000 Received: from gatekeeper.sgcs.co.uk (HELO bevx03.gpt.co.uk) (194.129.217.113) by iprelay.mail.pipex.net with SMTP; 9 Mar 2000 12:13:36 -0000 Received: from CONVERSION-DAEMON by siemenscomms.co.uk (PMDF V5.1-12 #D3115) id <01JMTUBQLBQ890OB9E@siemenscomms.co.uk>; Thu, 9 Mar 2000 12:13:24 GMT Received: from beex01.sgcs.co.uk ([19.0.53.101]) by siemenscomms.co.uk (PMDF V5.1-12 #D3115) with ESMTP id <01JMTUB1EF7490ODOK@siemenscomms.co.uk>; Thu, 09 Mar 2000 12:12:47 +0000 (GMT) Received: by beex01.sgcs.co.uk with Internet Mail Service (5.5.2448.0) id ; Thu, 09 Mar 2000 12:16:43 +0000 Content-return: allowed MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Message-ID: <5AC7D3F55147D311AA1700A0C99583ED2C3697@beex03.sgcs.co.uk> Date: Thu, 9 Mar 2000 12:16:38 +0000 Reply-To: "Drage, Keith" Sender: "Media Gateway Control (megaco)" Comments: *********************************************** Comments: * Our domain is now siemenscomms.co.uk * Comments: * Please update your address book accordingly * Comments: *********************************************** From: "Drage, Keith" Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7BIT See below. Keith Drage > --------------------------------------------------------------- > Keith Drage (keith.drage@siemenscomms.co.uk) > Siemens Communications Limited, > Technology Drive, Beeston, Nottingham NG9 1LA, UK > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > --------------------------------------------------------------- > Internet communications are not secure and therefore Siemens > Communications Limited does not accept legal responsibility for the > contents of this message. Any views or opinions presented are solely > those of the author and do not necessarily represent those of Siemens > Communications Limited unless otherwise specifically stated. > > -----Original Message----- > From: Rosen, Brian [mailto:brosen@FORE.COM] > Sent: Tuesday, March 07, 2000 4:22 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt > > > I'd go the other way. If a profile did NOT specify an > encoding (or failed > to > specify a minimum for any other option the protocol offers, > I'd say it was > deficient. Is this not tantamount to saying the protocol is deficient as well? > > I'll agree that subsetting where the protocol does not define > an option is > inappropriate. > > I really think that requiring an MG to have both binary and text is > unworkable Noone is proposing that an MG should implement both. All I have suggested is that an MG implementor should have the freedom to choose which they implement. This is a consequence of the MGC decision to go for SHOULD rather than MUST. My understanding of that decision is that it is up to the market to decide, not a profile creator. > for a really cost constrained design. The current MGC text is not > satisfactory > to anyone, including me. It was a compromise, and to this > day, I question > it's > appropriateness. Having been part of it, I'll live with it. > I don't want > to > see these kinds of compromises in profiles, regardless of how > the encoding > choice comes out; profiles should result in precise > interoperability for a > class of devices. Any less is unworkable, IMO. > > Brian > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 9 07:28:57 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13993 for ; Thu, 9 Mar 2000 07:28:56 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.86CBF110@standards.nortelnetworks.com>; Thu, 9 Mar 2000 7:24:37 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 81688 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Mar 2000 07:23:37 -0500 Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.611FEDE0@standards.nortelnetworks.com>; Thu, 9 Mar 2000 7:23:34 -0500 Received: from ficon-tech.com (sphilip.india.ficon-tech.com [172.25.1.104]) by ficon-tech.com (8.9.3/8.8.7) with ESMTP id RAA05770 for ; Thu, 9 Mar 2000 17:51:44 +0530 (IST) (envelope-from sphilip@ficon-tech.com) X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38C79859.CB9D775E@ficon-tech.com> Date: Thu, 9 Mar 2000 17:56:01 +0530 Reply-To: Shalini Philip Sender: "Media Gateway Control (megaco)" From: Shalini Philip Organization: Ficon Technology Subject: [Fwd: Issues in V16 Draft] To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello all, I did not get any response to the earlier mail. So I am resending it. There is some clarification required on some of the latest changes in V16 draft. They are: 1. Section 11.2 on Cold Start says that : "Upon failure to obtain a reply, either from the Primary MGC, or a designated successor, the MG tries its pre-provisioned Secondary MGCs, in order. If the MG is unable to comply and it has established a transport connection to the MGC, it should close that connection. In any event, it should reject all subsequent requests from the MGC with Error 406 Version Not Supported." The situation of MG not being able to comply and sending errors of Version not supported, seems to be appropriate only for the case of Version negotiation failure and not as a general case. If MG is unable to comply due to some other reason, then the appropriate error should be returned. 2. In Section 7.2.5, it is clarified that if DigitMap is requested in an AuditValue command with TerminationID ALL, then all the digit maps defined in the gateway are returned. Since only the digit map names are getting returned here, it would not be possible to return those digit maps specified by MGC as part of the Event Descriptor, since they do not have names associated with them. Regards, Shalini Philip Ficon Technology E-Mail : mailto:sphilip@ficon-tech.com Web : http://www.ficon-tech.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 9 07:48:05 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19854 for ; Thu, 9 Mar 2000 07:48:04 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2FBBB470@standards.nortelnetworks.com>; Thu, 9 Mar 2000 7:43:40 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 81720 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Mar 2000 07:41:50 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.88321B50@standards.nortelnetworks.com>; Thu, 9 Mar 2000 7:31:49 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id HAA09149; Thu, 9 Mar 2000 07:35:42 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id HAA09701; Thu, 9 Mar 2000 07:35:44 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Mar 2000 07:31:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF208A8C@whq-msgusr-02.fore.com> Date: Thu, 9 Mar 2000 07:35:21 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt X-To: "Drage, Keith" To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > I'd go the other way. If a profile did NOT specify an > > encoding (or failed > > to > > specify a minimum for any other option the protocol offers, > > I'd say it was > > deficient. > > Is this not tantamount to saying the protocol is deficient as well? No, the protocol allows options. In this case, the option leads to interoperability problems because the MGC is not obligated to support both. Conformance to a profile should, IMO guarantee interoperability. Therefore, a profile must define at least a minimum for encoding. > > > > I'll agree that subsetting where the protocol does not define > > an option is > > inappropriate. > > > > I really think that requiring an MG to have both binary and text is > > unworkable > > Noone is proposing that an MG should implement both. All I > have suggested is > that an MG implementor should have the freedom to choose which they > implement. This is a consequence of the MGC decision to go > for SHOULD rather > than MUST. My understanding of that decision is that it is up > to the market > to decide, not a profile creator. The consequence of SHOULD is that incompatibility is a real possibility. A profile should eliminate this possibility. A profile is a specification of a minimum. Perhaps the authors could consider changing the wording to make that explicit. Any implementation could offer more than a profile specifies, and still be compatible. Brian > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 9 08:36:27 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03415 for ; Thu, 9 Mar 2000 08:36:26 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E62508F0@standards.nortelnetworks.com>; Thu, 9 Mar 2000 8:31:43 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 81752 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Mar 2000 08:30:12 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4A170AE0@standards.nortelnetworks.com>; Thu, 9 Mar 2000 8:20:12 -0500 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id FAA19087; Thu, 9 Mar 2000 05:16:10 -0800 (PST) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF208A8A@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38C7A491.F74EB075@cisco.com> Date: Thu, 9 Mar 2000 08:18:09 -0500 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Subject: Re: Event handling questions X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit "Rosen, Brian" wrote: > I think there is no way an MGC is going to switch event buffering on and off > depending on what happens - either it will be set on and left, or set off > and > left. If it is on, there needs to be a way to clear the buffer. Send a single Notify. > If it is > off, > you never have the problem. > > I'd be okay in separating the controls (having two separate properties), but > at > this late date, it may not be worth it. I'll let Tom pass judgment on that. Look, although my preferences are probably well known here, I specifically did not ask for a protocal design change. I have simply reviewed the specification of the current design and noted a problem as well as offered a simple editorial in nature change to address it. -- Flemming > > > Brian > > > -----Original Message----- > > From: Flemming Andreasen [mailto:fandreas@cisco.com] > > Sent: Wednesday, March 08, 2000 10:37 AM > > To: Rosen, Brian > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Event handling questions > > > > > > > > > > "Rosen, Brian" wrote: > > > > > It seems to me that a particular MGC will either keep > > EventBufferControl on > > > or off. > > > There has to be a way to clear the buffer. Turning it from > > on to off seems > > > to be > > > an appropriate way to do that. > > > > You can argue either way, which is why I've always argued > > this should have been > > two instead of one parameter. In the absence of that the > > question then becomes > > whether you should always drop the events or not. The safe > > approach which > > satisfies all scenarios is not to drop them which actually > > has the effect of > > clearing the buffer as well since the MG is fully allowed to empty the > > eventbuffer in a single Notify message when EventBufferControl is off. > > Consequently I say they should not be dropped. > > > > > > > > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Flemming Andreasen [mailto:fandreas@cisco.com] > > > > Sent: Tuesday, March 07, 2000 11:04 AM > > > > To: MEGACO@standards.nortelnetworks.com > > > > Subject: Re: Event handling questions > > > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > > > > > > > > Replies below. > > > > > > > > > > -----Original Message----- > > > > > From: Flemming Andreasen [SMTP:fandreas@CISCO.COM] > > > > > Sent: Tuesday, March 07, 2000 10:03 AM > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Event handling questions > > > > > > > > > > A couple of questions on the event handling (7.1.9): > > > > > > > > > > 1. It is specified that "When the MG receives a > > command with a > > > > > new > > > > > EventsDescriptor, one or more events may have been > > buffered in > > > > > the > > > > > EventBuffer in the MG. The value of EventBufferControl then > > > > > determines > > > > > how the MG treats such buffered events." > > > > > > > > > > I assume that the "the value of EventBufferControl" > > > > refers to the > > > > > value > > > > > in the new command (if supplied), not the old, correct ? > > > > > [[TomT]] > > > > > That is correct. > > > > > > > > > > 2. It is specified that "If the MG receives a command > > > > instructing > > > > > it to > > > > > set the value of EventBufferControl to Off, all > > events in the > > > > > EventBuffer SHALL be discarded." > > > > > > > > > > This seems rather strange to me as you will be > > dropping events > > > > > for no > > > > > apparent reason. Can somebody please explain the > > > > rationale behind > > > > > this ? > > > > > > > > > > [[TomT]] If the MGC turns EventBufferControl off, it > > > > must have a > > > > > reason for doing so. The same reason presumably > > extends to the > > > > > treatment of events already in the buffer. > > > > > > > > > I don't follow. How does that justify throwing away the > > > > events that were > > > > already buffered ? The only thing you are changing is the way > > > > you report > > > > events. For example consider the case where the set of > > events to be > > > > detected in the two commands are exactly the same but the > > > > EventBufferControl differs. > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > Flemming > > > > > > > > > > -- > > > > > Flemming Andreasen > > > > > Cisco Systems > > > > > > > > > -- > > > > Flemming Andreasen > > > > Cisco Systems > > > > > > > > -- > > Flemming Andreasen > > Cisco Systems > > > > -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 9 08:36:27 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03417 for ; Thu, 9 Mar 2000 08:36:27 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E68921F0@standards.nortelnetworks.com>; Thu, 9 Mar 2000 8:31:44 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 81762 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Mar 2000 08:30:24 -0500 Received: from auemail2.firewall.lucent.com (192.11.223.163) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B6A0E180@standards.nortelnetworks.com>; Thu, 9 Mar 2000 8:30:23 -0500 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 IAA03324 for ; Thu, 9 Mar 2000 08:34:17 -0500 (EST) 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 IAA03312 for ; Thu, 9 Mar 2000 08:34:17 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA04045; Thu, 9 Mar 2000 14:34:16 +0100 (MET) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA04041; Thu, 9 Mar 2000 14:34:15 +0100 (MET) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF32EB28@whq-msgusr-02.fore.com> <38C673A5.6001A590@cisco.com> <38C77CA7.1F649403@lucent.com> <38C7A661.4E6832E0@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38C7A856.C4F1EDEA@lucent.com> Date: Thu, 9 Mar 2000 14:34:14 +0100 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: Event handling questions To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Flemming, Please see below. John Flemming Andreasen wrote: > > John Segers wrote: > > > Flemming, > > > > You're right in saying that it is not forbidden to have all events in > > the buffer notified in one go (although there is no text that says when > > one would include multiple events in one Notify). > > So add such a sentence or put it in an implementors guide. > > > Also, it is allowed > > for the MGC to send one message that audits the observed events > > descriptor (so it gets all events currently in the buffer), and clear > > the buffer by setting eventbuffercontrol to Off. So it seems to me that > > you can do what you want without changing the protocol. > > That's not clear. Section 7.2.9 on auditing context attributes specifies that the > values of the audited attributes returned are the values that result *after* the > manipulation request(s) have been processed. I would have thought the same applies to > auditing in a command. If not, I would say it needs to be spelled out. > > Besides, your proposal suffers from an event ordering problem. It is entirely > possible that the reply will arrive at the MGC after a new Notify issued does. Section 7.2.9 is indeed on _context_ attributes (note that the phrase "command" is not used in 7.2.9). Section 8 explains that _commands_ in a transaction are executed in the order they occur. AuditValue being a command, it is treated according to this ordered execution. I don't understand the ordering problem you refer to. When in LockStep mode, the MGC determines whether the MG can send a Notify. If it is expecting one, it would hold off on auditing the ObservedEventsDescriptor. Where does the ordering go wrong? > > And you have a means for the MGC to reduce the traffic if it really > > thinks that it doesn't need to see the buffered events. > > > > > Cheers, > > > > John [snip] -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 9 08:36:27 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03424 for ; Thu, 9 Mar 2000 08:36:27 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E6CBF750@standards.nortelnetworks.com>; Thu, 9 Mar 2000 8:31:44 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 81753 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Mar 2000 08:30:31 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5586E620@standards.nortelnetworks.com>; Thu, 9 Mar 2000 8:20:31 -0500 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id FAA19916; Thu, 9 Mar 2000 05:23:55 -0800 (PST) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF32EB28@whq-msgusr-02.fore.com> <38C673A5.6001A590@cisco.com> <38C77CA7.1F649403@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38C7A661.4E6832E0@cisco.com> Date: Thu, 9 Mar 2000 08:25:53 -0500 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Subject: Re: Event handling questions X-To: John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit John Segers wrote: > Flemming, > > You're right in saying that it is not forbidden to have all events in > the buffer notified in one go (although there is no text that says when > one would include multiple events in one Notify). So add such a sentence or put it in an implementors guide. > Also, it is allowed > for the MGC to send one message that audits the observed events > descriptor (so it gets all events currently in the buffer), and clear > the buffer by setting eventbuffercontrol to Off. So it seems to me that > you can do what you want without changing the protocol. That's not clear. Section 7.2.9 on auditing context attributes specifies that the values of the audited attributes returned are the values that result *after* the manipulation request(s) have been processed. I would have thought the same applies to auditing in a command. If not, I would say it needs to be spelled out. Besides, your proposal suffers from an event ordering problem. It is entirely possible that the reply will arrive at the MGC after a new Notify issued does. > > And you have a means for the MGC to reduce the traffic if it really > thinks that it doesn't need to see the buffered events. > > Cheers, > > John -- Flemming > > > Flemming Andreasen wrote: > > > > "Rosen, Brian" wrote: > > > > > It seems to me that a particular MGC will either keep EventBufferControl on > > > or off. > > > There has to be a way to clear the buffer. Turning it from on to off seems > > > to be > > > an appropriate way to do that. > > > > You can argue either way, which is why I've always argued this should have been > > two instead of one parameter. In the absence of that the question then becomes > > whether you should always drop the events or not. The safe approach which > > satisfies all scenarios is not to drop them which actually has the effect of > > clearing the buffer as well since the MG is fully allowed to empty the > > eventbuffer in a single Notify message when EventBufferControl is off. > > Consequently I say they should not be dropped. > > > > > > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Flemming Andreasen [mailto:fandreas@cisco.com] > > > > Sent: Tuesday, March 07, 2000 11:04 AM > > > > To: MEGACO@standards.nortelnetworks.com > > > > Subject: Re: Event handling questions > > > > > > > > > > > > Tom-PT Taylor wrote: > > > > > > > > > > > > > > > > > > > Replies below. > > > > > > > > > > -----Original Message----- > > > > > From: Flemming Andreasen [SMTP:fandreas@CISCO.COM] > > > > > Sent: Tuesday, March 07, 2000 10:03 AM > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Event handling questions > > > > > > > > > > A couple of questions on the event handling (7.1.9): > > > > > > > > > > 1. It is specified that "When the MG receives a command with a > > > > > new > > > > > EventsDescriptor, one or more events may have been buffered in > > > > > the > > > > > EventBuffer in the MG. The value of EventBufferControl then > > > > > determines > > > > > how the MG treats such buffered events." > > > > > > > > > > I assume that the "the value of EventBufferControl" > > > > refers to the > > > > > value > > > > > in the new command (if supplied), not the old, correct ? > > > > > [[TomT]] > > > > > That is correct. > > > > > > > > > > 2. It is specified that "If the MG receives a command > > > > instructing > > > > > it to > > > > > set the value of EventBufferControl to Off, all events in the > > > > > EventBuffer SHALL be discarded." > > > > > > > > > > This seems rather strange to me as you will be dropping events > > > > > for no > > > > > apparent reason. Can somebody please explain the > > > > rationale behind > > > > > this ? > > > > > > > > > > [[TomT]] If the MGC turns EventBufferControl off, it > > > > must have a > > > > > reason for doing so. The same reason presumably extends to the > > > > > treatment of events already in the buffer. > > > > > > > > > I don't follow. How does that justify throwing away the > > > > events that were > > > > already buffered ? The only thing you are changing is the way > > > > you report > > > > events. For example consider the case where the set of events to be > > > > detected in the two commands are exactly the same but the > > > > EventBufferControl differs. > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > Flemming > > > > > > > > > > -- > > > > > Flemming Andreasen > > > > > Cisco Systems > > > > > > > > > -- > > > > Flemming Andreasen > > > > Cisco Systems > > > > > > > > -- > > Flemming Andreasen > > Cisco Systems > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 306 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 9 09:16:23 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15487 for ; Thu, 9 Mar 2000 09:16:22 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.81572920@standards.nortelnetworks.com>; Thu, 9 Mar 2000 9:11:51 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 81844 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Mar 2000 09:10:07 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DDA3EC60@standards.nortelnetworks.com>; Thu, 9 Mar 2000 9:00:07 -0500 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id GAA25849; Thu, 9 Mar 2000 06:03:55 -0800 (PST) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF32EB28@whq-msgusr-02.fore.com> <38C673A5.6001A590@cisco.com> <38C77CA7.1F649403@lucent.com> <38C7A661.4E6832E0@cisco.com> <38C7A856.C4F1EDEA@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38C7AFB7.A9F73C9D@cisco.com> Date: Thu, 9 Mar 2000 09:05:43 -0500 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Subject: Re: Event handling questions X-To: John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit John Segers wrote: > Flemming, > > Please see below. > > John > > Flemming Andreasen wrote: > > > > John Segers wrote: > > > > > Flemming, > > > > > > You're right in saying that it is not forbidden to have all events in > > > the buffer notified in one go (although there is no text that says when > > > one would include multiple events in one Notify). > > > > So add such a sentence or put it in an implementors guide. > > > > > Also, it is allowed > > > for the MGC to send one message that audits the observed events > > > descriptor (so it gets all events currently in the buffer), and clear > > > the buffer by setting eventbuffercontrol to Off. So it seems to me that > > > you can do what you want without changing the protocol. > > > > That's not clear. Section 7.2.9 on auditing context attributes specifies that the > > values of the audited attributes returned are the values that result *after* the > > manipulation request(s) have been processed. I would have thought the same applies to > > auditing in a command. If not, I would say it needs to be spelled out. > > > > Besides, your proposal suffers from an event ordering problem. It is entirely > > possible that the reply will arrive at the MGC after a new Notify issued does. > > Section 7.2.9 is indeed on _context_ attributes (note that the phrase > "command" is not used in 7.2.9). Section 8 explains that _commands_ in > a transaction are executed in the order they occur. AuditValue being a > command, it is treated according to this ordered execution. If you try to use two commands, one to audit, and another to change EventBufferControl, then there's clearly a window between the two that will allow one or more additional events to occur, which will then be lost. You need some kind of exclusive access here, and the closest you will get is to use a single command the way the protocol is defined. Consequently, for your solution, it becomes important to know precisely how a command is actually executed. > > > > I don't understand the ordering problem you refer to. When in LockStep > mode, the MGC determines whether the MG can send a Notify. If it is > expecting one, it would hold off on auditing the > ObservedEventsDescriptor. Where does the ordering go wrong? Trouble is that detecting and reporting events are two different things. Regardless of whether you are in LockStep mode or not, events can continuously be added to the eventbuffer. Thus separate actions, commands or transaction will not work. If we go back to a single command that then tries to achieve what we are looking for by auditing observed events and changing the events descriptor at the same time we observe that the is no ordering requirement between 1. A transaction reply 2. A Notify command Consequently 2 may arrive at the MGC before 1 and you have out of order event reporting (irrespective of what one might think about using audits to do event "reporting") > > > > > And you have a means for the MGC to reduce the traffic if it really > > > thinks that it doesn't need to see the buffered events. > > > > > > > > Cheers, > > > > > > John > > [snip] > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 306 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 -- Flemming -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 9 10:07:34 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01391 for ; Thu, 9 Mar 2000 10:07:34 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AAA3CE80@standards.nortelnetworks.com>; Thu, 9 Mar 2000 10:03:07 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 81971 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Mar 2000 10:02:15 -0500 Received: from hoemail2.firewall.lucent.com (192.11.226.163) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8BA9F770@standards.nortelnetworks.com>; Thu, 9 Mar 2000 10:02:15 -0500 Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA25321 for ; Thu, 9 Mar 2000 10:06:09 -0500 (EST) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA25294 for ; Thu, 9 Mar 2000 10:06:08 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA20203; Thu, 9 Mar 2000 16:06:08 +0100 (MET) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA20189; Thu, 9 Mar 2000 16:06:06 +0100 (MET) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF32EB28@whq-msgusr-02.fore.com> <38C673A5.6001A590@cisco.com> <38C77CA7.1F649403@lucent.com> <38C7A661.4E6832E0@cisco.com> <38C7A856.C4F1EDEA@lucent.com> <38C7AFB7.A9F73C9D@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38C7BDDD.7F4F02C7@lucent.com> Date: Thu, 9 Mar 2000 16:06:05 +0100 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: Event handling questions To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Flemming Andreasen wrote: [snip] > > Section 7.2.9 is indeed on _context_ attributes (note that the phrase > > "command" is not used in 7.2.9). Section 8 explains that _commands_ in > > a transaction are executed in the order they occur. AuditValue being a > > command, it is treated according to this ordered execution. > > If you try to use two commands, one to audit, and another to change EventBufferControl, > then there's clearly a window between the two that will allow one or more additional events > to occur, which will then be lost. You need some kind of exclusive access here, and the > closest you will get is to use a single command the way the protocol is defined. > Consequently, for your solution, it becomes important to know precisely how a command is > actually executed. Actually, in my solution you can do it in one command. You can include an AuditDescriptor in the Modify that changes the value of EventBufferControl. > > I don't understand the ordering problem you refer to. When in LockStep > > mode, the MGC determines whether the MG can send a Notify. If it is > > expecting one, it would hold off on auditing the > > ObservedEventsDescriptor. Where does the ordering go wrong? > > Trouble is that detecting and reporting events are two different things. Regardless of > whether you are in LockStep mode or not, events can continuously be added to the > eventbuffer. Thus separate actions, commands or transaction will not work. If we go back to > a single command that then tries to achieve what we are looking for by auditing observed > events and changing the events descriptor at the same time we observe that the is no > ordering requirement between > 1. A transaction reply > 2. A Notify command > Consequently 2 may arrive at the MGC before 1 and you have out of order event reporting > (irrespective of what one might think about using audits to do event "reporting") I think that it is important whether you are in LockStep mode or not. When in LockStep, the MGC determines when the MG will send a NotifyRequest. So, the MGC should take care not to allow the ordering problem to occur. If it doesn't do so, then the time stamps on events allow the MGC to determine the order in which events occurred if a NotifyRequest and ModifyReply (or AuditReply) containing observed events occur independently. [snip] John -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 9 10:51:46 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15654 for ; Thu, 9 Mar 2000 10:51:45 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D5F7AB00@standards.nortelnetworks.com>; Thu, 9 Mar 2000 10:47:16 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 82075 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Mar 2000 10:45:37 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9A723DC0@standards.nortelnetworks.com>; Thu, 9 Mar 2000 10:45:36 -0500 Received: from zmers013 by smtprch1.nortel.com; Thu, 9 Mar 2000 09:48:42 -0600 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by zmers013; Thu, 9 Mar 2000 10:48:19 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 9 Mar 2000 10:48:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF89DE.E2F73EA4" Message-ID: <29400B68197CD31188830000F8CD15D343BC99@zcard00q.ca.nortel.com> Date: Thu, 9 Mar 2000 10:48:14 -0500 Reply-To: Peter Blatherwick Sender: "Media Gateway Control (megaco)" From: Peter Blatherwick Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt X-To: "Drage, Keith" 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_01BF89DE.E2F73EA4 Content-Type: text/plain Keith, list: I strongly agree with Brian and others here. I believe what we specifying by making minimum decisions on encoding and transport is absolutely required to make the application viable, does not affect other applications, and is exactly what profiles are intended to do. I do not think the protocol is deficient. Profiling is an extremely valuable aspect of the protocol, especially when combined with the flexibility and extensibility of packages. Profiles allow us to make critical decisions on the optional parts for specific applications, while not restricting how other applications work in any way. This both enables interoperability and reduces complexity for the specific application. And these decisions set the minimum requirement, not exclusive requirement. Such decisions are absolutely required for small scale, focused applications, of which IP Phone MG is just one example. As Brian suggests, we will clarify the wording in that area. -- Peter Blatherwick > -----Original Message----- > From: Rosen, Brian [SMTP:brosen@FORE.COM] > Sent: 9 Mar, 2000 07:35 > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt > > > > I'd go the other way. If a profile did NOT specify an > > > encoding (or failed > > > to > > > specify a minimum for any other option the protocol offers, > > > I'd say it was > > > deficient. > > > > Is this not tantamount to saying the protocol is deficient as well? > > No, the protocol allows options. In this case, the option leads to > interoperability problems because the MGC is not obligated to support > both. > Conformance to a profile should, IMO guarantee interoperability. > Therefore, > a profile must define at least a minimum for encoding. > > > > > > > > I'll agree that subsetting where the protocol does not define > > > an option is > > > inappropriate. > > > > > > I really think that requiring an MG to have both binary and text is > > > unworkable > > > > Noone is proposing that an MG should implement both. All I > > have suggested is > > that an MG implementor should have the freedom to choose which they > > implement. This is a consequence of the MGC decision to go > > for SHOULD rather > > than MUST. My understanding of that decision is that it is up > > to the market > > to decide, not a profile creator. > The consequence of SHOULD is that incompatibility is a real possibility. > A profile should eliminate this possibility. A profile is a specification > of > a minimum. Perhaps the authors could consider changing the wording to > make > that > explicit. Any implementation could offer more than a profile specifies, > and > still > be compatible. > > Brian > > > ------_=_NextPart_001_01BF89DE.E2F73EA4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-megaco-ipphone-02.txt

Keith, list:

I strongly agree = with Brian and others here.  I believe what we specifying by = making minimum decisions on encoding and transport is absolutely = required to make the application viable, does not affect other = applications, and is exactly what profiles are intended to do.  =

I do not think the = protocol is deficient.  Profiling is an extremely valuable aspect = of the protocol, especially when combined with the flexibility and = extensibility of packages. 

Profiles allow us to = make critical decisions on the optional parts for specific = applications, while not restricting how other applications work in any = way.  This both enables interoperability and reduces complexity = for the specific application.  And these decisions set the minimum = requirement, not exclusive requirement.  Such decisions are = absolutely required for small scale, focused applications, of which IP = Phone MG is just one example. 

As Brian suggests, = we will clarify the wording in that area.  

-- Peter = Blatherwick



    -----Original Message-----
    From:   Rosen, Brian [SMTP:brosen@FORE.COM]
    Sent:   9 Mar, 2000 07:35
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: I-D = ACTION:draft-ietf-megaco-ipphone-02.txt

    > > I'd go the other way.  = If a profile did NOT specify an
    > > encoding (or failed
    > > to
    > > specify a minimum for any = other option the protocol offers,
    > > I'd say it was
    > > deficient.
    >
    > Is this not tantamount to saying = the protocol is deficient as well?

    No, the protocol allows options.  = In this case, the option leads to
    interoperability problems because the = MGC is not obligated to support both.
    Conformance to a profile should, IMO = guarantee interoperability.  Therefore,
    a profile must define at least a = minimum for encoding.


    > >
    > > I'll agree that subsetting = where the protocol does not define
    > > an option is
    > > inappropriate.
    > >
    > > I really think that = requiring an MG to have both binary and text is
    > > unworkable
    >
    > Noone is proposing that an MG = should implement both. All I
    > have suggested is
    > that an MG implementor should = have the freedom to choose which they
    > implement. This is a consequence = of the MGC decision to go
    > for SHOULD rather
    > than MUST. My understanding of = that decision is that it is up
    > to the market
    > to decide, not a profile = creator.
    The consequence of SHOULD is that = incompatibility is a real possibility.
    A profile should eliminate this = possibility.  A profile is a specification
    of
    a minimum.  Perhaps the authors = could consider changing the wording to make
    that
    explicit. Any implementation could = offer more than a profile specifies, and
    still
    be compatible.

    Brian

    >

------_=_NextPart_001_01BF89DE.E2F73EA4-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 9 15:22:05 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11400 for ; Thu, 9 Mar 2000 15:22:03 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.84BF0410@standards.nortelnetworks.com>; Thu, 9 Mar 2000 15:17:01 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 82606 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Mar 2000 15:16:26 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.09F7DA50@standards.nortelnetworks.com>; Thu, 9 Mar 2000 15:06:25 -0500 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id MAA05711; Thu, 9 Mar 2000 12:10:18 -0800 (PST) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF32EB28@whq-msgusr-02.fore.com> <38C673A5.6001A590@cisco.com> <38C77CA7.1F649403@lucent.com> <38C7A661.4E6832E0@cisco.com> <38C7A856.C4F1EDEA@lucent.com> <38C7AFB7.A9F73C9D@cisco.com> <38C7BDDD.7F4F02C7@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38C8054E.93EB49A1@cisco.com> Date: Thu, 9 Mar 2000 15:10:54 -0500 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Subject: Re: Event handling questions X-To: John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit John Segers wrote: > Flemming Andreasen wrote: > > [snip] > > > > Section 7.2.9 is indeed on _context_ attributes (note that the phrase > > > "command" is not used in 7.2.9). Section 8 explains that _commands_ in > > > a transaction are executed in the order they occur. AuditValue being a > > > command, it is treated according to this ordered execution. > > > > If you try to use two commands, one to audit, and another to change EventBufferControl, > > then there's clearly a window between the two that will allow one or more additional events > > to occur, which will then be lost. You need some kind of exclusive access here, and the > > closest you will get is to use a single command the way the protocol is defined. > > Consequently, for your solution, it becomes important to know precisely how a command is > > actually executed. > > Actually, in my solution you can do it in one command. You can include > an AuditDescriptor in the Modify that changes the value of > EventBufferControl. > > > > I don't understand the ordering problem you refer to. When in LockStep > > > mode, the MGC determines whether the MG can send a Notify. If it is > > > expecting one, it would hold off on auditing the > > > ObservedEventsDescriptor. Where does the ordering go wrong? > > > > Trouble is that detecting and reporting events are two different things. Regardless of > > whether you are in LockStep mode or not, events can continuously be added to the > > eventbuffer. Thus separate actions, commands or transaction will not work. If we go back to > > a single command that then tries to achieve what we are looking for by auditing observed > > events and changing the events descriptor at the same time we observe that the is no > > ordering requirement between > > 1. A transaction reply > > 2. A Notify command > > Consequently 2 may arrive at the MGC before 1 and you have out of order event reporting > > (irrespective of what one might think about using audits to do event "reporting") > > I think that it is important whether you are in LockStep mode or not. > When in LockStep, the MGC determines when the MG will send a > NotifyRequest. So, the MGC should take care not to allow the ordering > problem to occur. You are missing the point. The MGC has no way of preventing it from occurring. It is an inherent "feature" > If it doesn't do so, then the time stamps on events > allow the MGC to determine the order in which events occurred if a > NotifyRequest and ModifyReply (or AuditReply) containing observed events > occur independently. Well that now assumes that auditing is done prior to the command being executed as opposed to after which hasn't been clarified/resolved yet. Even so, this "reporting" via auditing seems a rather strange design to me. In any case, I've provided my comment and made my point. Doesn't seem like much will be achieved by continuing this discussion. -- Flemming -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 9 20:59:59 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18160 for ; Thu, 9 Mar 2000 20:59:59 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CBB615F0@standards.nortelnetworks.com>; Thu, 9 Mar 2000 20:55:26 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 82965 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Mar 2000 20:53:31 -0500 Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.214BCB10@standards.nortelnetworks.com>; Thu, 9 Mar 2000 20:43:31 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id CAA02262; Fri, 10 Mar 2000 02:47:09 +0100 (MET) 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 CAA25126; Fri, 10 Mar 2000 02:47:08 +0100 (MET) Received: from ericsson.com (7-130.epa.ericsson.se [146.11.7.130]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id CAA15814; Fri, 10 Mar 2000 02:47:05 +0100 (MET) X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: <20000307131300.AAA14744@q17326> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38C84D4A.CC9578DE@ericsson.com> Date: Fri, 10 Mar 2000 02:18:02 +0100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Questions About MEGACO/H.248 Version 16 X-To: Xiuping Qiu To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Xiuping, A streamDescriptor doesn't describe streams between terminations. Cheers, Christian Xiuping Qiu wrote: > > Hi, Tom-PT Taylor ,list > > Still question on stream. > > May StreamDescriptor describe streams between terminations in a same context? > > If so, I think there are at least 2 streams within a termination. > One stream flows to the exterior of the context , > the other flows to other termination, > In the figure below, termination T1 has 2 streams : S1 and S3. > And termination T2 has S2 and S4. > S1 flows to the exterior of the context, S3 flows to other termination. > > I wonder the relationships of S1,S2,S3,S4 if T1 and T2 are connected. > such as which are specified by StreamID , the equal relationship , which > equals to which then the streams aare connected, and so on. > > +------------------------------------+ > | Context | > | | > S1 | +----+ S3 S4 +----+ | S2 > ----------- | |------*---- | |------------- > | | T1 | | T2 | | > | +----+ +----+ | > | | > +------------------------------------+ > > >> 2. In 7.1.6 Stream Descriptor > >> > >> " StreamIDs are of local significance between MGC and MG and they are > >> assigned by the MGC. Within a context, StreamID is a means by which to > >> indicate which media flows are interconnected: streams with the same > >> StreamID are connected " > >> > >> I am wondering whether StreamID will conflict with Topology. > >> > >> Let's suppose there are 2 Terminations ( T1 and T2) in a context . There > >> is one stream on the 2 Terminations each but the StreamIDs are different. > >> So the media flows are not interconnected. But if the Topology Descriptor > >> of the Context is > >> Bothway", What will happen? > > [[TomT]] > > Topology is sort of a global property -- it defines > >inter-termination connectivity regardless of the details of which streams > >are flowing. Streams add a level of detail within that framework: A may > >talk to B in general, but B doesn't happen to support the video that A is > >prepared to provide. One could conceive of making topology stream-specific, > >but I don't think there's a real requirement for that level of control. > > > > Regards, > Xiuping Qiu > _______________________________________________ > > Xiuping Qiu > Huawei Technologies Co., Ltd. > Mail to: qiuxiuping@sz.huawei.com.cn > Tel : +86 755 654 4482 > Visit : http://www.huawei.com.cn > _______________________________________________ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 9 21:15:47 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23002 for ; Thu, 9 Mar 2000 21:15:47 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.093126C0@standards.nortelnetworks.com>; Thu, 9 Mar 2000 21:11:28 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 82990 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 9 Mar 2000 21:10:09 -0500 Received: from firewall.hypercom.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.73E88EB0@standards.nortelnetworks.com>; Thu, 9 Mar 2000 21:00:08 -0500 Received: by firewall.hypercom.com; id SAA10931; Thu, 9 Mar 2000 18:41:01 -0700 (MST) Received: from unknown(10.0.2.39) by firewall.hypercom.com via smap (V5.0) id xma010921; Thu, 9 Mar 00 18:40:40 -0700 Received: from Azphxn01.hypercom.com (azphxn01.hypercom.com [10.0.2.70]) by citadel.hypercom.com (8.8.8/8.8.8) with ESMTP id TAA18938 for ; Thu, 9 Mar 2000 19:04:11 -0700 (MST) X-Priority: 3 (Normal) X-MIMETrack: Serialize by Router on AZPHXN01/Hypercom/US(Release 5.0.2b |December 16, 1999) at 03/09/2000 07:02:06 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: Date: Thu, 9 Mar 2000 19:02:05 -0700 Reply-To: Manish Rao Sender: "Media Gateway Control (megaco)" From: Manish Rao To: MEGACO@STANDARDS.NORTELNETWORKS.COM Please be advised of my new email address: manish_rao@cirilium.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 10 03:12:21 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28805 for ; Fri, 10 Mar 2000 03:12:19 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CEE07D40@standards.nortelnetworks.com>; Fri, 10 Mar 2000 3:07:45 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 83185 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Mar 2000 03:06:22 -0500 Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9CE22E10@standards.nortelnetworks.com>; Fri, 10 Mar 2000 3:06:21 -0500 Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id JAA20896 for ; Fri, 10 Mar 2000 09:10:14 +0100 (MET) Received: from uabs28 (uabs28i3 [134.138.201.3]) by ms.uab.ericsson.se (8.9.3/8.9.3/uab-2.21) with ESMTP id JAA06195 for ; Fri, 10 Mar 2000 09:10:13 +0100 (MET) Received: from uab.ericsson.se by uabs28 (8.8.8+Sun/client-1.3uab2) id JAA16970; Fri, 10 Mar 2000 09:10:13 +0100 (MET) X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------DB497CA9935111B4F29CD03E" Message-ID: <38C8ADE4.810F73FF@uab.ericsson.se> Date: Fri, 10 Mar 2000 09:10:12 +0100 Reply-To: Alf Heidermark Sender: "Media Gateway Control (megaco)" From: Alf Heidermark Organization: Ericsson Utvecklings AB Subject: Editorials To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------DB497CA9935111B4F29CD03E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I have found two editorials related to the error codes. Section7.3 > > Error code 403 shall be syntax error in TransactionRequest to be > consequent with the other error codes (404, 405) > > 8.2.2 > > Last paragraph, it is said error code 442 syntax error in transaction. > It shall be syntax error in command. --------------DB497CA9935111B4F29CD03E Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Description: Card for Alf Heidermark Content-Disposition: attachment; filename="vcard.vcf" Content-Transfer-Encoding: 7bit begin: vcard fn: Alf Heidermark n: Heidermark;Alf org: Ericsson Core Network product email;internet: Alf.Heidermark@uab.ericsson.se note;quoted-printable:Telphone number +4687273894=0D=0A= Mobile: +46703997883=0D=0A= Address: Armborstv=E4gen 14=0D=0A= =C4lvsj=F6 x-mozilla-cpt: ;0 x-mozilla-html: FALSE version: 2.1 end: vcard --------------DB497CA9935111B4F29CD03E-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 10 06:50:17 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06468 for ; Fri, 10 Mar 2000 06:50:17 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.488E8FB0@standards.nortelnetworks.com>; Fri, 10 Mar 2000 6:45:54 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 83294 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Mar 2000 06:44:07 -0500 Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A28BE4B0@standards.nortelnetworks.com>; Fri, 10 Mar 2000 6:34:06 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id MAA03194 for ; Fri, 10 Mar 2000 12:38:03 +0100 (MET) 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 MAA09973 for ; Fri, 10 Mar 2000 12:38:00 +0100 (MET) Received: from ericsson.com (7-130.epa.ericsson.se [146.11.7.130]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id MAA18309 for ; Fri, 10 Mar 2000 12:37:57 +0100 (MET) X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38C8DE96.BDA801D9@ericsson.com> Date: Fri, 10 Mar 2000 12:37:58 +0100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Pontential Error in 11.4 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day all, Should the following text (11.4): Upon failover, the Primary MG sends a ServiceChange command with a "Failover" method and a "MG Impending Failure" reason. The MGC then uses the primary MG as the active MG. When the error condition is repaired, the Working MG can send a "ServiceChange" with a "Restart" method. instead read: Upon failover, the Primary MG sends a ServiceChange command with a "Failover" method and a "MG Impending Failure" reason. The MGC then uses the <> MG as the active MG. When the error condition is repaired, the Working MG can send a "ServiceChange" with a "Restart" method. Cheers, Christian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 10 08:05:35 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02405 for ; Fri, 10 Mar 2000 08:05:35 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C499BC10@standards.nortelnetworks.com>; Fri, 10 Mar 2000 8:00:57 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 83332 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Mar 2000 07:59:16 -0500 Received: from hoemlsrv.firewall.lucent.com (192.11.226.161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.87F8A5A0@standards.nortelnetworks.com>; Fri, 10 Mar 2000 7:59:16 -0500 Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA29050 for ; Fri, 10 Mar 2000 08:03:13 -0500 (EST) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA29035 for ; Fri, 10 Mar 2000 08:03:12 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA13216; Fri, 10 Mar 2000 14:03:12 +0100 (MET) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA13212; Fri, 10 Mar 2000 14:03:11 +0100 (MET) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <38C79859.CB9D775E@ficon-tech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38C8F28D.BC9CA1DD@lucent.com> Date: Fri, 10 Mar 2000 14:03:09 +0100 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: [Fwd: Issues in V16 Draft] To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Philip, Some response this time. Please see below. John Shalini Philip wrote: > > Hello all, > I did not get any response to the earlier mail. So I am resending it. > > There is some clarification required on some of the latest changes > in V16 draft. They are: > > 1. Section 11.2 on Cold Start says that : > "Upon failure to obtain a reply, either from the Primary MGC, or a > designated successor, the MG tries its pre-provisioned Secondary MGCs, > in order. If the MG is unable to comply and it has established a > transport connection to the MGC, it should close that connection. In any > event, it should reject all subsequent requests from the MGC with Error > 406 Version Not Supported." > The situation of MG not being able to comply and sending errors of > Version not supported, seems to be appropriate only for the case of > Version negotiation failure and not as a general case. If MG is unable > to comply due to some other reason, then the appropriate error should be > returned. I checked back in my notes from the ITU meeting and before, and found out that the offending text has been introduced in January (on the 24th). I don't remember who suggested the change at that time. All I remember is that there was a request to put in text about the error message to be returned. Even for that purpose, the text looks strange (what does "comply" refer to?). Suggestions? > 2. In Section 7.2.5, it is clarified that if DigitMap is requested in an > AuditValue command with TerminationID ALL, then all the digit maps > defined in the gateway are returned. Since only the digit map names are > getting returned here, it would not be possible to return those digit > maps specified by MGC as part of the Event Descriptor, since they do not > have names associated with them. For the case that one termination is addressed, the text reads "DigitMapDescriptor returns the name or value of the current DigitMap for the Termination.", which I interpreted as: if the DM has a name, the name is returned, otherwise the value. I have to admit that the text is not very clear, but your assumption that only names can be returned does not seem right. > Regards, > > Shalini Philip > Ficon Technology > E-Mail : mailto:sphilip@ficon-tech.com > Web : http://www.ficon-tech.com -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 10 08:05:36 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02408 for ; Fri, 10 Mar 2000 08:05:35 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C4E60750@standards.nortelnetworks.com>; Fri, 10 Mar 2000 8:00:58 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 83337 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Mar 2000 08:00:49 -0500 Received: from hoemlsrv.firewall.lucent.com (192.11.226.161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BF70EF10@standards.nortelnetworks.com>; Fri, 10 Mar 2000 8:00:49 -0500 Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA29925 for ; Fri, 10 Mar 2000 08:04:46 -0500 (EST) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA29903 for ; Fri, 10 Mar 2000 08:04:45 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA13554; Fri, 10 Mar 2000 14:04:44 +0100 (MET) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA13534; Fri, 10 Mar 2000 14:04:38 +0100 (MET) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Original-CC: MEGACO@standards.nortelnetworks.com References: <38C8ADE4.810F73FF@uab.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38C8F2E4.754685A1@lucent.com> Date: Fri, 10 Mar 2000 14:04:36 +0100 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: Editorials X-To: Alf Heidermark To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Alf, I agree that these are errors and propose that we accept your resolutions. John Alf Heidermark wrote: > > I have found two editorials related to the error codes. > > Section7.3 > > > > Error code 403 shall be syntax error in TransactionRequest to be > > consequent with the other error codes (404, 405) > > > > 8.2.2 > > > > Last paragraph, it is said error code 442 syntax error in transaction. > > It shall be syntax error in command. -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 10 08:11:18 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04526 for ; Fri, 10 Mar 2000 08:11:17 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9E401E50@standards.nortelnetworks.com>; Fri, 10 Mar 2000 8:07:03 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 83399 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Mar 2000 08:06:55 -0500 Received: from hoemlsrv.firewall.lucent.com (192.11.226.161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9990EE20@standards.nortelnetworks.com>; Fri, 10 Mar 2000 8:06:55 -0500 Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA04271 for ; Fri, 10 Mar 2000 08:10:52 -0500 (EST) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA04249 for ; Fri, 10 Mar 2000 08:10:51 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA14369; Fri, 10 Mar 2000 14:10:51 +0100 (MET) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA14365; Fri, 10 Mar 2000 14:10:50 +0100 (MET) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <38C8DE96.BDA801D9@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38C8F459.C33E3C75@lucent.com> Date: Fri, 10 Mar 2000 14:10:49 +0100 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: Pontential Error in 11.4 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Christian, I have to admit that it seems strange to say that an MGC has to use the primary MG if that same primary MG has just indicated an impending failure. This is a typo and we should fix it like you propose. John Christian Groves wrote: > > G'Day all, > > Should the following text (11.4): > Upon failover, the Primary MG sends a ServiceChange command with a > "Failover" method and a "MG Impending Failure" reason. The MGC then > uses the primary MG as the active MG. When the error condition is > repaired, the Working MG can send a "ServiceChange" with a "Restart" > method. > > instead read: > > Upon failover, the Primary MG sends a ServiceChange command with a > "Failover" method and a "MG Impending Failure" reason. The MGC then > uses the <> MG as the active MG. When the error condition is > repaired, the Working MG can send a "ServiceChange" with a "Restart" > method. > > Cheers, Christian -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 10 09:20:48 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28421 for ; Fri, 10 Mar 2000 09:20:48 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.44E418C0@standards.nortelnetworks.com>; Fri, 10 Mar 2000 9:16:08 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 83459 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Mar 2000 09:14:51 -0500 Received: from mailrelay2.alcatel.de by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B1ACD480@standards.nortelnetworks.com>; Fri, 10 Mar 2000 9:04:51 -0500 Received: from slsms1a.stgl.netd.alcatel.de by mailrelay2.alcatel.de with SMTP (XT-PP) with ESMTP; Fri, 10 Mar 2000 15:07:22 +0100 Received: from localhost (root@localhost) by slsms1a.stgl.netd.alcatel.de (8.8.6 (PHNE_17190)/8.8.6) with SMTP id PAA05941 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Mar 2000 15:07:49 +0100 (MET) X-OpenMail-Hops: 1 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; name="Last" Content-Disposition: inline; filename="Last" Content-Transfer-Encoding: 7bit Message-ID: Date: Fri, 10 Mar 2000 15:07:44 +0100 Reply-To: P.Kotar@ALCATEL.DE Sender: "Media Gateway Control (megaco)" From: Peter Kotar Subject: Last termination - Moved/Substratcted To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hallo Considering the last termination in a context is moved or substracted. What happens with the context? Is it deleted? Is there any specific error code for that (e.g. 400)? Peter Kotar From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 10 09:20:49 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28434 for ; Fri, 10 Mar 2000 09:20:48 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.452E1A10@standards.nortelnetworks.com>; Fri, 10 Mar 2000 9:16:08 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 83464 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Mar 2000 09:15:32 -0500 Received: from mailrelay2.alcatel.de by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2F419D30@standards.nortelnetworks.com>; Fri, 10 Mar 2000 9:15:31 -0500 Received: from slsms1a.stgl.netd.alcatel.de by mailrelay2.alcatel.de with SMTP (XT-PP) with ESMTP; Fri, 10 Mar 2000 15:18:43 +0100 Received: from localhost (root@localhost) by slsms1a.stgl.netd.alcatel.de (8.8.6 (PHNE_17190)/8.8.6) with SMTP id PAA12356 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Mar 2000 15:19:10 +0100 (MET) X-OpenMail-Hops: 1 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; name="Re:Last" Content-Disposition: inline; filename="Re:Last" Content-Transfer-Encoding: 7bit Message-ID: Date: Fri, 10 Mar 2000 15:19:02 +0100 Reply-To: P.Kotar@ALCATEL.DE Sender: "Media Gateway Control (megaco)" From: Peter Kotar Subject: Re: Last termination - Moved/Substratcted To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit No answer required!! Output document of Geneva contains answer in chapter 6.1.2 Peter Kotar From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 10 11:12:50 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03969 for ; Fri, 10 Mar 2000 11:12:49 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F0F6B410@standards.nortelnetworks.com>; Fri, 10 Mar 2000 11:08:19 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 83572 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Mar 2000 11:06:43 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.522E29E0@standards.nortelnetworks.com>; Fri, 10 Mar 2000 10:56:43 -0500 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id IAA00719; Fri, 10 Mar 2000 08:00:35 -0800 (PST) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <38C79859.CB9D775E@ficon-tech.com> <38C8F28D.BC9CA1DD@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38C91CEF.8C7BEB8A@cisco.com> Date: Fri, 10 Mar 2000 11:03:59 -0500 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Subject: Re: [Fwd: Issues in V16 Draft] X-To: John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit John Segers wrote: > Philip, > > Some response this time. Please see below. > > John > > Shalini Philip wrote: > > > > Hello all, > > I did not get any response to the earlier mail. So I am resending it. > > > > There is some clarification required on some of the latest changes > > in V16 draft. They are: > > > > 1. Section 11.2 on Cold Start says that : > > "Upon failure to obtain a reply, either from the Primary MGC, or a > > designated successor, the MG tries its pre-provisioned Secondary MGCs, > > in order. If the MG is unable to comply and it has established a > > transport connection to the MGC, it should close that connection. In any > > event, it should reject all subsequent requests from the MGC with Error > > 406 Version Not Supported." > > The situation of MG not being able to comply and sending errors of > > Version not supported, seems to be appropriate only for the case of > > Version negotiation failure and not as a general case. If MG is unable > > to comply due to some other reason, then the appropriate error should be > > returned. > > I checked back in my notes from the ITU meeting and before, and found > out that the offending text has been introduced in January (on the > 24th). I don't remember who suggested the change at that time. All I > remember is that there was a request to put in text about the error > message to be returned. Even for that purpose, the text looks strange > (what does "comply" refer to?). Suggestions? I made the same comment and I think you are looking at Section 11.3, not 11.2. The change got introduced in v16, and when you look at a similar change made in Section 11.3 it seems like a simple editorial mistake. If it's not, discussion is clearly needed. > > > > 2. In Section 7.2.5, it is clarified that if DigitMap is requested in an > > AuditValue command with TerminationID ALL, then all the digit maps > > defined in the gateway are returned. Since only the digit map names are > > getting returned here, it would not be possible to return those digit > > maps specified by MGC as part of the Event Descriptor, since they do not > > have names associated with them. > > For the case that one termination is addressed, the text reads > "DigitMapDescriptor returns the name or value of the current DigitMap > for the Termination.", which I interpreted as: if the DM has a name, the > name is returned, otherwise the value. I have to admit that the text is > not very clear, but your assumption that only names can be returned does > not seem right. > There is however another issue of shadowing between the root termination and other terminations. > > > Regards, > > > > Shalini Philip > > Ficon Technology > > E-Mail : mailto:sphilip@ficon-tech.com > > Web : http://www.ficon-tech.com > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 306 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 -- Flemming -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 10 16:41:49 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00007 for ; Fri, 10 Mar 2000 16:41:49 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E2D9CB50@standards.nortelnetworks.com>; Fri, 10 Mar 2000 16:37:12 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 84180 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Mar 2000 16:36:52 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D6E46C60@standards.nortelnetworks.com>; Fri, 10 Mar 2000 16:36:52 -0500 Received: from zmers013 by smtprch1.nortel.com; Fri, 10 Mar 2000 15:26:48 -0600 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by zmers013; Fri, 10 Mar 2000 16:26:32 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 10 Mar 2000 16:25:07 -0500 X-Mailer: Internet Mail Service (5.5.2650.21) Message-ID: Date: Fri, 10 Mar 2000 16:25:06 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: FW: Questions on MEGACO/H.248 v16 - More To: MEGACO@STANDARDS.NORTELNETWORKS.COM Resend. > -----Original Message----- > From: Taylor, Tom-PT [CAR:B904:EXCH] > Sent: Tuesday, March 07, 2000 11:25 PM > To: 'Xiuping Qiu'; 'Megaco' > Subject: RE: Questions on MEGACO/H.248 v16 - More > > Thank you for the questions. I do wonder if we have to write a new > document collecting all the explanations. Maybe a list of frequently > asked questions (FAQ). > > My responses below. > > -----Original Message----- > From: Xiuping Qiu [SMTP:qiuxiuping@SZ.HUAWEI.COM.CN] > Sent: Tuesday, March 07, 2000 7:27 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Questions on MEGACO/H.248 v16 - More > > Hi, all > > Thanks for those who reponses me. > Also thanks for you who reads my questions. > > 1. When ReserveValue and ReserveGroup are true , how the parameters > of Value and Group are matched? > [[TomT]] > I'm not clear what you mean by "matched". Do you mean matching of > alternatives selected in Local against alternatives selected in Remote? > > And if ReserveValue and ReserveGroup are true, will it return large > numbers of info? For example,if ReserveValue is true,and there is a > "m=audio $ RTP/AVP 0 " line in Local Descriptor,then should MG return > all possible port numbers to MGC? > [[TomT]] > Remember to start with that the MG is reserving resources. These > resources will therefore be unavailable to serve other calls until the MGC > releases them by being more selective in its requests. In our > interpretation of the different syntactic possibilities and how the MG > should react to them, we should be looking for principles that lead to > reasonable behaviour. > > Now, what are the syntactic possibilities for any parameter? In > text-encoded terms, they are: > > (a) "$" also known as CHOOSE. The most reasonable interpretation, > particularly in the light of your example, is that "$" always asks the MG > to choose a single value for the parameter concerned. Again, for your > particular example, if there are multiple session descriptions and > ReserveGroup is TRUE, it would make sense for the MG to reserve the same > port for audio in every session description it returns, since the > assumption is that only one of these session descriptions will be chosen > in the end. > > (b) A comma-separated list of values enclosed within brackets. Here the > assumption should be that the values are listed in descending order of > preference, and subject to that ordering the MG should reserve resources > to cover as many of the values as possible. ("Cover" means that it is > prepared for the MGC or the far end to select that value to be the one > actually used.) We have a problem here: SDP does not support the same > syntax for a list of alternatives, so how does the MG provide a response > which is properly-formed SDP? The brute force answer is to use SDP > mechanisms for the purpose where they exist, and otherwise spell out > alternatives in multiple session descriptions. The problem with the > latter is that the required number of session descriptions will grow > exponentially with the number of parameters for which alternatives are > supplied. Perhaps someone can think of a more clever answer. > > (c) A bracket-enclosed range of values. It is harder here to think that > the ordering implicit in the range represents any sort of order of > preference. Instead, I propose that the intent is that the MG be prepared > to support as many values as possible within that range. If it weren't > for the rule that the MG must respond with proper SDP syntax, the MG would > respond either with a range which may be a subset of the original or with > a list of individual values selected from the range. The brute force > means of conforming to SDP syntax is even more difficult than in the > previous case. Help! > > (d) An inequality constraint. The same logic that applies to ranges also > applies to inequalities. > > > 2. In 7.1.8 Local and Remote Descriptors > > (a) An unspecified Local or Remote descriptor is considered to be > a missing mandatory parameter. It requires the MG to use whatever > was last specified for that descriptor. It is possible that there was > no previously-specified value, in which case the descriptor concerned > is ignored in further processing of the command. > > It seems that the above conflicts with the Example of Appendix A. > [[TomT]] > Which step? > > 3. ?If the Mode property of the LocalControl descriptor is RecvOnly or > SendRecv, the MG must be prepared to receive media encoded according to > any of the alternatives included in its response to the MGC. ? > > Question :What exact alternative does MG use to receive media? e.g. When > the peer MG has sent media encoded in one of the alternatives,how does the > prepared MG know what type is the encoding? > [[TomT]] > It's shown by the payload type in the RTP header. > > 4. E.6.2 Events > > Original: > Termination Method > ParameterID: Meth (0x0003) > Type: enumeration > Possible values: > "UM" (0x0001) Unambiguous match > "PM" (0x0002) Partial match, completion by timer expiry or > unmatched event > "FM" (0x0003) Full match, completion by timer expiry or unmatched > event > Description: indicates the reason for generation of the event. See the > procedures in section . > > Question : > While dialing the MG detects the onhook events, then will it happen the > DigitMapCompletion event? If it happens, what the kind of Termination > Method is ? > And, Which event happens first ? Onhook or DigitMap Completion? > [[TomT]] > The usual case would be that the EventsDescriptor changes as a result of > on-hook. If this doesn't happen, DigitMapCompletion will come about as a > result of timer expiry, and thus will generally follow some time after the > on-hook. > > 5. 7.1.9 Events Descriptor > > Question: > In Case 1, EventBufferControl = LockStep ,EventBuffer is empty,Will > EventDescriptor > and EventBufferDescriptor both work ? If they both work, suppose one > event exists > in both Descriptors, Then how to deal with it ? > [[TomT]] > Events are never screened against both EventDescriptor and > EventBufferDescriptor at the same time. In the case you give, the next > arriving event will be screened against the EventDescriptor only, reported > if it is matched, and discarded if it is not matched. If it is matched, > subsequent events will be screened against the EventBufferDescriptor and > placed in the EventBuffer until a new EventDescriptor is activated. > > 6. Question: > > Before replaced by a new one, can an EventDescriptor be used to detect > specified events > more than once? I.e. One EventDescriptor contains an EventID dt , after > detected once, > if event dt happened again , and the EventDescriptor is not replaced. Will > the MG Notify > the event? > [[TomT]] > This will happen if EventBufferControl = "off". > > > Thanks, > Xiuping Qiu > _______________________________________________ > > Xiuping Qiu > Huawei Technologies Co., Ltd. > Mail to: qiuxiuping@sz.huawei.com.cn > Tel : +86 755 6544482 > Visit : http://www.huawei.com.cn > _______________________________________________ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 10 16:41:50 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00010 for ; Fri, 10 Mar 2000 16:41:49 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E32D4280@standards.nortelnetworks.com>; Fri, 10 Mar 2000 16:37:13 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 84185 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Mar 2000 16:36:52 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D711BDF0@standards.nortelnetworks.com>; Fri, 10 Mar 2000 16:36:52 -0500 Received: from zmers013 by smtprch1.nortel.com; Fri, 10 Mar 2000 15:25:07 -0600 Received: from zrchb213.us.nortel.com (actually zrchb213) by zmers013; Fri, 10 Mar 2000 16:24:48 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 10 Mar 2000 15:24:46 -0600 X-Mailer: Internet Mail Service (5.5.2650.21) Message-ID: Date: Fri, 10 Mar 2000 15:24:34 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Comments on draft-ietf-megaco-protocol-07 X-To: Flemming Andreasen To: MEGACO@STANDARDS.NORTELNETWORKS.COM My responses below. Consider them attempts at clarification. Final resolution undoubtedly requires further discussion. > -----Original Message----- > From: Flemming Andreasen [SMTP:fandreas@cisco.com] > Sent: Tuesday, March 07, 2000 8:28 PM > To: Taylor, Tom-PT [CAR:B904:EXCH]; Megaco > Subject: Comments on draft-ietf-megaco-protocol-07 > > Greetings > > Below you will find some comments on draft-ietf-megaco-protocol-07.txt. > > > 1) 6.2.2, second last paragraph: It is still unclear to me what > these "UNION" responses look like, at least if something besides the > terminationID is returned. Please clarify. [[TomT]] My understanding is that for every parameter that occurs at least once in the set of responses, the audit will return the complete list of values taken on by that parameter over all of the responses being summarized. Others may have a different view, in which case clarifying text is probably needed. > 2) 7.1.8, last bullet in second last bullet list: Shouldn't the MG > also be prepared to receive media if Mode is loopback ? [[TomT]] I suppose. The error comes from my thinking of loopback in terms of a wire, when actually it probably requires the assignment of a DSP resource. I expect loopback with an arbitrary payload type is easier to provide than sending or receiving an arbitrary payload type. > 3) 7.1.9, last sentence in the paragraph "When the MG receives a command > with a new EventsDescriptor, one or more events may have been buffered > in the EventBuffer i nthe MG. The value of EventBufferControl then > determines how the MG treats such buffered events" should be clarified > to indicate that the EventBufferControl referred to is the one for the > new command. > > 4) 7.1.9, the paragraph "If the MG receives a command instructing it to > set the value of EventBufferControl to Off, all events in the > EventBuffer SHALL be discarded" should be removed as there seems to be > no good reason for loosing those events. [[TomT]] Maybe Michael Brown has commented -- I know that this was a deliberate rather than accidental choice when he and Chip were working out the details of the language. You do get an anomalous transient condition where buffering has been deactivated but the buffer has content, but in fact the buffer can be cleared in a single transaction. Brian mentioned the need to clear a buffer sometimes, but you can do that by including a Modify with an empty Event Descriptor within a transaction, preceding the command containing the new Event Descriptor. > 5) 7.1.11, second paragraph: The granularity of the signal completion > event defined in E.1.2 is too coarse. There is for example no way to be > informed of just failures (which would seem generally desirable) without > being more or less flooded by the other completion reasons as well (some > of which are more questionable). One simple way out of this is to extend > the definition of the signal completion event to include > EventsDescriptorParameters where the TerminationMethod(s) of interest > could be specified. Also, the term "notifyCompletion" is somewhat of a > misnomer. [[TomT]] Your suggestion is a possibility. Another is to assume that the failures you're really interested in are covered by the Generic/Cause event (which IMHO belongs in Network rather than Generic, but that's another story). We'll have to see what other people have to say about this. > 6) 7.1.11, last bullet list and sentence before that seems redundant > with the KeepActive flag and could/should consequently be removed. [[TomT]] It's talking about sequential signal lists rather than individual signals. Lists need special treatment. > 7) 7.1.14, last sentence in paragraph beginning with "The letter 'x' is > used as a wildcard..." specifies that "As a consequence of the thrid > timing rule above, inter-event timing while matching the dot symbol uses > the short timer by default." is incorrect. The grammar may continue past > the dot symbol implying the dot could only possibly produce a partial > match which furthermore implies that the short timer may not be the > right one to use. The sentence should simply be removed. [[TomT]] Agreed that the grammar may continue past the dot, but until you get that far you have an ambiguous situation -- you don't know how many events will be mapped into the dot. The sentence is correct AFAIK. > 8) 7.1.14, next paragraph specifies that "A timer specified following a > dot specifies inter-event timing for all events matching the dot as well > as for subsequent events". It's unclear why the timer couldn't simply be > put in front of the dot and thereby be consistent with digit map timers > in general. In the absence of a compelling argument the sentence should > simply be removed. [[TomT]] Same problem as with the previous remark -- you don't know when you've gone past the dot until it's too late. If there is a timer both before and after the dot, a timer after the dot never gets used. It may be better just to say that, I suppose, leaving it up to the MGC to set a timer before the dot if it wants. > 9) 7.1.14, numbered list, item 4: The second sentence and the last > sentence seem to contradict each other. While absence of long-duration > may prevent a match from occurring, existence of long-duration should > not. Consequently, the second sentence is what should be modified. [[TomT]] I assume you mean the last sentence of the paragraph. You will reach this case only if all of the alternatives specifying a long-duration event at this point have been discarded. Thus duration becomes irrelevant, but only after it has been taken into account in the cases where it mattered. > 10) 7.1.14, numbered list, item 5 specifies that "If exactly one > candidate remains, a completion event is generated indicating an > unambiguous match". This seems to imply that even a partial match (as > long as there is only one) will result in a digit map completion event, > which of course is incorrect. [[TomT]] Good catch. This really is an error. We should change that to "If exactly one candidate remains and it is fully matched, ..." > 11) 7.1.14, numbered list, item 5: It is entirely unclear why an > event triggering a partial match is not reported as part of the matched > string. In the absence of a compelling argument, the triggering event > should be included in the string as it otherwise may be processed twice, > which is hardly what the user had in mind. [[TomT]] I had it that way in the first place (with the triggering event distinguished by being placed in an "extra event" parameter) and consensus was to change it to what it is now. Have to overrule you on this one unless you get more support. I'm also not clear how you get duplicate processing -- the situation is logically equivalent to the triggering event (a non-matching digit) happening just after the digit completion event has been notified. > 12) 7.1.14, second last paragraph states that "Regardles of whether a > digit map is activated, this form of event specification will cause the > individual events to be reported to the MGC as they are detected". Some > clarification is requested here. [[TomT]] This paragraph gives the interpretation of e.g. the "dd/*" event specification. Using the example digit map which immediately follows, a dialled "1" will be reported immediately and also accumulated into the digit map. Of course, if EventBufferControl is set to LockStep, the digit map will never complete because a new Event Descriptor will be loaded before completion can be reported. (There is a corner case with a dialled "0" and short timer expiry before the new Event descriptor is loaded, but let's not go into that.) > 13) 7.1.17, first paragraph states that "Used with the AuditValue > command, the ObservedEventsDescriptor returns events in the event buffer > which have not been Notified". It should be clarified whether that > includes events that are being matched against a digit map or not. [[TomT]] Opinions? I don't have any. > 14) 7.2.3, bullet list, first item states that [property values revert > to] "the default value, if specified for the property and not overriden > by provisioning". The provisioning part seems to contradict Section > 6.2.4 and furthermore be redundant with the following bullet. > Consequently, the provisioning part in the first bullet should simply be > deleted. [[TomT]] Actually, 6.2.4 is probably in error, since this is the most recently modified section. Other opinions? > 15) 7.2.5, fourth paragraph states that "Digitmap requested in an > AuditValue command with TerminationID ALL returns all DigitMaps in the > gateway". Since digitmaps defined on specific terminations "shadow" > digit maps defined on the root termination, it would seem that digit > maps defined on root should be excluded here (unless the reporting > starts including the termination the digit map is defined on which seems > to be a more substantial change). [[TomT]] Why can't the sentence mean what it says? A digit map is a name and a value. This paragraph doesn't say that the same digit map is reported multiple times, which I think is what you are implying. > 16) 7.2.8, Restart: As I have stated before, it is a mistake that the > gateway is not defined to be in a clean and well-defined state when > "Restart" is issued. Consequently, I suggest that the sentence "the > Terminations are assumed to now not be associated with any Context" is > put back in this defintion again. [[TomT]] You were overruled by prevailing consensus. Basically the view is that the MGC is responsible for controlling the state of terminations, aside from in-service/test/out-of-service. If it really wants to clear all contexts it has the tools to do that. > 17) 7.2.8, paragraph beginning with "A ServiceChange Command > specifying..." states that "Acknowledgement of the ServiceChange Command > completes the registration process", however this seems to conflict with > the procedures specified later, where it is in fact determined by the > MGCId returned (if it's the same, registration completed). The sentence > should be modified accordingly. [[TomT]] You have a point. > 18) 7.2.9, last paragraph specifies that "If a MG receives an action > which contains both a request to audit context attributes and a request > to manipulate those attributes, the response SHALL include the values of > the attributes after processing the manipulation request". While the > above behavior makes sense for a *command*, it does not for a action and > furthermore it is in conflict with the general command processing order > defined in Section 8. The sentence should be modified accordingly [[TomT]] You're right. > 19) 8: It is still unclear whether commands are atomic or not. At the > very least this needs to be clarified as well as what effect a failed > command may have on a gateway/termination. [[TomT]] No consensus on this. > 20a) 11.2, first paragraph, last sentence: Editorial mistake (cf. > 11.3) ? Sentence should be brought back to "If the MG is unable to > establish a control relationship with any MGC, it shall wait a random > amount of time as described in Section 9.2 and then start contacting its > primary, and if necessary, its secondary MGCs again" [[TomT]] I think you're right. > 20b) 12.1.4, specifies that "Signals that would be played with > SignalType BR should have a default duration". The same should be > specified for signals with SignalType TO. [[TomT]] Makes sense to me. > 21) D.1, first paragraph, last sentence specifies that "Responses must > be sent to the address and port from which the corresponding commands > were sent except if the response to a handoff or failover, in which case > the procedures of 11.5 apply". While this may be reasonable for > clustered systems, it does not seem reasonable for handoff between > non-clustered systems. To enable reliable delivery of this message, the > response should still be sent to the source of the request, but > otherwise the procedures of 11.5 applies. [[TomT]] Sorry, what's the difference between what you propose and what's there now? > 22) D.1.1, second paragraph, last line: The reference to Section > 8.2.3 should be replace with a reference to Section D.1.4, as this > section describes UDP specific requirements, where as 8.2.3 is transport > independent and consequently has looser specification language ("may"). [[TomT]] Or perhaps both references, since you need both to tell the whole story. > 23) D.1.4, first paragraph The sentence "They should send this > response if they receive a repetition of a transaction that is still > being executed" has been deleted. The sentence should be added back in > again. [[TomT]] Seems reasonable. Comments? > 24) D.1.4, last paragraph specifies that "Upon receipt of of a final > response, an immediate confirmation shall be sent, and normal repetition > timers shall be used thereafter", however it is not specified how the > entity determines whether the final response needs to be confirmed > immediately or not (consider the case where the pending was lost). A > specification for this needs to be added. > > 25) D.1.5, last paragraph specifies that "When the MG establishes a new > control association, it can retransmit to the new MGC. Alternatively, a > MG may use a ServiceChange with ServiceChangeMethod equal to > disconnected to inform the new MGC that the MG lost one or more > transaction". In order to prevent duplicate transactions, it must be > required that transactions cannot be retransmitted T-MAX time after > their initial transmission. Consequently, a disconnected ServiceChange > *must* be issued in such cases. > > 26), E.1.2, Signal Completion: See issue 5 > > 27), E.9.2, onhook/offhook: The text specifies that if > "onhook/ofhook" is requested while the phone is already onhook/offhook, > an onhook/offhook event will be generated. This behavior does not handle > glare properly and may consequently result in two onhook/offhook events > being generated for a single onhook/offhook transition. As part of glare > handling, it is furthermore important to enable a coupling between an > expected hook-state and the application of signals. One way of > accomplishing the above would simply be to define a couple of event > parameters for onhook and offhook: > A. No expected hook-state, just report next transition. > B. Expected hook-state, report if hook-state differs (the current text). > > C. Expected hook-state must be met or command will fail. [[TomT]] I like this -- since the alternatives are mutually exclusive it would be just one parameter. Other views? > 28) E.10.2, specifies that "If the return tone is detected before the > signal times out, the cmp event shall be generated with the value...". > In practice, there may be a little more to the test (e.g. successful > removal of the tone again) so the success criteria should probably be a > little more general and simply refer to a successful test or not. > > > > Regards > > Flemming > > > -- > Flemming Andreasen > Cisco Systems > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 10 19:20:18 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24999 for ; Fri, 10 Mar 2000 19:20:18 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FD12BCF0@standards.nortelnetworks.com>; Fri, 10 Mar 2000 19:15:25 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 84334 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Mar 2000 19:13:48 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5DA0FA70@standards.nortelnetworks.com>; Fri, 10 Mar 2000 19:03:48 -0500 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id QAA09173; Fri, 10 Mar 2000 16:07:38 -0800 (PST) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38C98EDE.6802425F@cisco.com> Date: Fri, 10 Mar 2000 19:10:06 -0500 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Subject: Re: Comments on draft-ietf-megaco-protocol-07 X-To: Tom-PT Taylor X-cc: Flemming Andreasen To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Tom Thanks for the responses. Rather than continuing all of these in a single e-mail, let me break out some of them as indicated below. Tom-PT Taylor wrote: > My responses below. Consider them attempts at clarification. Final > resolution undoubtedly requires further discussion. > > > -----Original Message----- > > From: Flemming Andreasen [SMTP:fandreas@cisco.com] > > Sent: Tuesday, March 07, 2000 8:28 PM > > To: Taylor, Tom-PT [CAR:B904:EXCH]; Megaco > > Subject: Comments on draft-ietf-megaco-protocol-07 > > > > Greetings > > > > Below you will find some comments on draft-ietf-megaco-protocol-07.txt. > > > > > > 1) 6.2.2, second last paragraph: It is still unclear to me what > > these "UNION" responses look like, at least if something besides the > > terminationID is returned. Please clarify. > [[TomT]] My understanding is that for every parameter that occurs > at least once in the set of responses, the audit will return the complete > list of values taken on by that parameter over all of the responses being > summarized. Others may have a different view, in which case clarifying text > is probably needed. > An example would probably clear this. > > > 2) 7.1.8, last bullet in second last bullet list: Shouldn't the MG > > also be prepared to receive media if Mode is loopback ? > [[TomT]] I suppose. The error comes from my thinking of loopback > in terms of a wire, when actually it probably requires the assignment of a > DSP resource. I expect loopback with an arbitrary payload type is easier to > provide than sending or receiving an arbitrary payload type. > > > 3) 7.1.9, last sentence in the paragraph "When the MG receives a command > > with a new EventsDescriptor, one or more events may have been buffered > > in the EventBuffer i nthe MG. The value of EventBufferControl then > > determines how the MG treats such buffered events" should be clarified > > to indicate that the EventBufferControl referred to is the one for the > > new command. > > > > 4) 7.1.9, the paragraph "If the MG receives a command instructing it to > > set the value of EventBufferControl to Off, all events in the > > EventBuffer SHALL be discarded" should be removed as there seems to be > > no good reason for loosing those events. > [[TomT]] Maybe Michael Brown has commented -- I know that this was > a deliberate rather than accidental choice when he and Chip were working out > the details of the language. You do get an anomalous transient condition > where buffering has been deactivated but the buffer has content, but in fact > the buffer can be cleared in a single transaction. Brian mentioned the need > to clear a buffer sometimes, but you can do that by including a Modify with > an empty Event Descriptor within a transaction, preceding the command > containing the new Event Descriptor. I've gotten comments from John Segers, but we didn't seem to get anywhere. Although I disagree, we can leave 4) as is since we can always define a new EventBufferControl value. > > > 5) 7.1.11, second paragraph: The granularity of the signal completion > > event defined in E.1.2 is too coarse. There is for example no way to be > > informed of just failures (which would seem generally desirable) without > > being more or less flooded by the other completion reasons as well (some > > of which are more questionable). One simple way out of this is to extend > > the definition of the signal completion event to include > > EventsDescriptorParameters where the TerminationMethod(s) of interest > > could be specified. Also, the term "notifyCompletion" is somewhat of a > > misnomer. > [[TomT]] Your suggestion is a possibility. Another is to assume > that the failures you're really interested in are covered by the > Generic/Cause event (which IMHO belongs in Network rather than Generic, but > that's another story). We'll have to see what other people have to say > about this. I suppose you could if we clarified the description to state that signal failures would be covered as well. > > > > 6) 7.1.11, last bullet list and sentence before that seems redundant > > with the KeepActive flag and could/should consequently be removed. > [[TomT]] It's talking about sequential signal lists rather than > individual signals. Lists need special treatment. Well, the special treatment seems to be exactly what KeepActive does, but no big deal. > > > > 7) 7.1.14, last sentence in paragraph beginning with "The letter 'x' is > > used as a wildcard..." specifies that "As a consequence of the thrid > > timing rule above, inter-event timing while matching the dot symbol uses > > the short timer by default." is incorrect. The grammar may continue past > > the dot symbol implying the dot could only possibly produce a partial > > match which furthermore implies that the short timer may not be the > > right one to use. The sentence should simply be removed. > [[TomT]] Agreed that the grammar may continue past the dot, but > until you get that far you have an ambiguous situation -- you don't know how > many events will be mapped into the dot. The sentence is correct AFAIK. > > > 8) 7.1.14, next paragraph specifies that "A timer specified following a > > dot specifies inter-event timing for all events matching the dot as well > > as for subsequent events". It's unclear why the timer couldn't simply be > > put in front of the dot and thereby be consistent with digit map timers > > in general. In the absence of a compelling argument the sentence should > > simply be removed. > [[TomT]] Same problem as with the previous remark -- you don't know > when you've gone past the dot until it's too late. If there is a timer both > before and after the dot, a timer after the dot never gets used. It may be > better just to say that, I suppose, leaving it up to the MGC to set a timer > before the dot if it wants. > > > 9) 7.1.14, numbered list, item 4: The second sentence and the last > > sentence seem to contradict each other. While absence of long-duration > > may prevent a match from occurring, existence of long-duration should > > not. Consequently, the second sentence is what should be modified. > [[TomT]] I assume you mean the last sentence of the paragraph. You > will reach this case only if all of the alternatives specifying a > long-duration event at this point have been discarded. Thus duration > becomes irrelevant, but only after it has been taken into account in the > cases where it mattered. > > > 10) 7.1.14, numbered list, item 5 specifies that "If exactly one > > candidate remains, a completion event is generated indicating an > > unambiguous match". This seems to imply that even a partial match (as > > long as there is only one) will result in a digit map completion event, > > which of course is incorrect. > [[TomT]] Good catch. This really is an error. We should change > that to "If exactly one candidate remains and it is fully matched, ..." > > > 11) 7.1.14, numbered list, item 5: It is entirely unclear why an > > event triggering a partial match is not reported as part of the matched > > string. In the absence of a compelling argument, the triggering event > > should be included in the string as it otherwise may be processed twice, > > which is hardly what the user had in mind. > [[TomT]] I had it that way in the first place (with the triggering > event distinguished by being placed in an "extra event" parameter) and > consensus was to change it to what it is now. Have to overrule you on this > one unless you get more support. I'm also not clear how you get duplicate > processing -- the situation is logically equivalent to the triggering event > (a non-matching digit) happening just after the digit completion event has > been notified. > > > 12) 7.1.14, second last paragraph states that "Regardles of whether a > > digit map is activated, this form of event specification will cause the > > individual events to be reported to the MGC as they are detected". Some > > clarification is requested here. > [[TomT]] This paragraph gives the interpretation of e.g. the "dd/*" > event specification. Using the example digit map which immediately follows, > a dialled "1" will be reported immediately and also accumulated into the > digit map. Of course, if EventBufferControl is set to LockStep, the digit > map will never complete because a new Event Descriptor will be loaded before > completion can be reported. (There is a corner case with a dialled "0" and > short timer expiry before the new Event descriptor is loaded, but let's not > go into that.) Separate e-mail on 7.1.14. > > > > 13) 7.1.17, first paragraph states that "Used with the AuditValue > > command, the ObservedEventsDescriptor returns events in the event buffer > > which have not been Notified". It should be clarified whether that > > includes events that are being matched against a digit map or not. > [[TomT]] Opinions? I don't have any. > > > 14) 7.2.3, bullet list, first item states that [property values revert > > to] "the default value, if specified for the property and not overriden > > by provisioning". The provisioning part seems to contradict Section > > 6.2.4 and furthermore be redundant with the following bullet. > > Consequently, the provisioning part in the first bullet should simply be > > deleted. > [[TomT]] Actually, 6.2.4 is probably in error, since this is the > most recently modified section. Other opinions? > > > 15) 7.2.5, fourth paragraph states that "Digitmap requested in an > > AuditValue command with TerminationID ALL returns all DigitMaps in the > > gateway". Since digitmaps defined on specific terminations "shadow" > > digit maps defined on the root termination, it would seem that digit > > maps defined on root should be excluded here (unless the reporting > > starts including the termination the digit map is defined on which seems > > to be a more substantial change). > [[TomT]] Why can't the sentence mean what it says? A digit map is > a name and a value. This paragraph doesn't say that the same digit map is > reported multiple times, which I think is what you are implying. See separate e-mail > > > > 16) 7.2.8, Restart: As I have stated before, it is a mistake that the > > gateway is not defined to be in a clean and well-defined state when > > "Restart" is issued. Consequently, I suggest that the sentence "the > > Terminations are assumed to now not be associated with any Context" is > > put back in this defintion again. > [[TomT]] You were overruled by prevailing consensus. Basically the > view is that the MGC is responsible for controlling the state of > terminations, aside from in-service/test/out-of-service. If it really wants > to clear all contexts it has the tools to do that. See separate e-mail Certainly not on the mailing list. There were only a few mails exchanged on this issue, in particular by Chip, Brian, and myself. I never got a response/resolution to the last one I sent out. > > > > 17) 7.2.8, paragraph beginning with "A ServiceChange Command > > specifying..." states that "Acknowledgement of the ServiceChange Command > > completes the registration process", however this seems to conflict with > > the procedures specified later, where it is in fact determined by the > > MGCId returned (if it's the same, registration completed). The sentence > > should be modified accordingly. > [[TomT]] You have a point. > > > 18) 7.2.9, last paragraph specifies that "If a MG receives an action > > which contains both a request to audit context attributes and a request > > to manipulate those attributes, the response SHALL include the values of > > the attributes after processing the manipulation request". While the > > above behavior makes sense for a *command*, it does not for a action and > > furthermore it is in conflict with the general command processing order > > defined in Section 8. The sentence should be modified accordingly > [[TomT]] You're right. > > > 19) 8: It is still unclear whether commands are atomic or not. At the > > very least this needs to be clarified as well as what effect a failed > > command may have on a gateway/termination. > [[TomT]] No consensus on this. So it's basically undefined. > > > > 20a) 11.2, first paragraph, last sentence: Editorial mistake (cf. > > 11.3) ? Sentence should be brought back to "If the MG is unable to > > establish a control relationship with any MGC, it shall wait a random > > amount of time as described in Section 9.2 and then start contacting its > > primary, and if necessary, its secondary MGCs again" > [[TomT]] I think you're right. > > > 20b) 12.1.4, specifies that "Signals that would be played with > > SignalType BR should have a default duration". The same should be > > specified for signals with SignalType TO. > [[TomT]] Makes sense to me. > > > 21) D.1, first paragraph, last sentence specifies that "Responses must > > be sent to the address and port from which the corresponding commands > > were sent except if the response to a handoff or failover, in which case > > the procedures of 11.5 apply". While this may be reasonable for > > clustered systems, it does not seem reasonable for handoff between > > non-clustered systems. To enable reliable delivery of this message, the > > response should still be sent to the source of the request, but > > otherwise the procedures of 11.5 applies. > [[TomT]] Sorry, what's the difference between what you propose and > what's there now? See separate e-mail > > > > 22) D.1.1, second paragraph, last line: The reference to Section > > 8.2.3 should be replace with a reference to Section D.1.4, as this > > section describes UDP specific requirements, where as 8.2.3 is transport > > independent and consequently has looser specification language ("may"). > [[TomT]] Or perhaps both references, since you need both to tell > the whole story. > > > 23) D.1.4, first paragraph The sentence "They should send this > > response if they receive a repetition of a transaction that is still > > being executed" has been deleted. The sentence should be added back in > > again. > [[TomT]] Seems reasonable. Comments? > > > 24) D.1.4, last paragraph specifies that "Upon receipt of of a final > > response, an immediate confirmation shall be sent, and normal repetition > > timers shall be used thereafter", however it is not specified how the > > entity determines whether the final response needs to be confirmed > > immediately or not (consider the case where the pending was lost). A > > specification for this needs to be added. Didn't see a response here. > > > > > 25) D.1.5, last paragraph specifies that "When the MG establishes a new > > control association, it can retransmit to the new MGC. Alternatively, a > > MG may use a ServiceChange with ServiceChangeMethod equal to > > disconnected to inform the new MGC that the MG lost one or more > > transaction". In order to prevent duplicate transactions, it must be > > required that transactions cannot be retransmitted T-MAX time after > > their initial transmission. Consequently, a disconnected ServiceChange > > *must* be issued in such cases. Didn't see a response here. > > > > > 26), E.1.2, Signal Completion: See issue 5 > > > > 27), E.9.2, onhook/offhook: The text specifies that if > > "onhook/ofhook" is requested while the phone is already onhook/offhook, > > an onhook/offhook event will be generated. This behavior does not handle > > glare properly and may consequently result in two onhook/offhook events > > being generated for a single onhook/offhook transition. As part of glare > > handling, it is furthermore important to enable a coupling between an > > expected hook-state and the application of signals. One way of > > accomplishing the above would simply be to define a couple of event > > parameters for onhook and offhook: > > A. No expected hook-state, just report next transition. > > B. Expected hook-state, report if hook-state differs (the current text). > > > > C. Expected hook-state must be met or command will fail. > [[TomT]] I like this -- since the alternatives are mutually > exclusive it would be just one parameter. Other views? > > > 28) E.10.2, specifies that "If the return tone is detected before the > > signal times out, the cmp event shall be generated with the value...". > > In practice, there may be a little more to the test (e.g. successful > > removal of the tone again) so the success criteria should probably be a > > little more general and simply refer to a successful test or not. > > > > > > > > Regards > > > > Flemming > > > > > > -- > > Flemming Andreasen > > Cisco Systems > > > > -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 10 19:23:48 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26071 for ; Fri, 10 Mar 2000 19:23:47 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8FCB29B0@standards.nortelnetworks.com>; Fri, 10 Mar 2000 19:19:31 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 84341 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Mar 2000 19:19:21 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.241CBEF0@standards.nortelnetworks.com>; Fri, 10 Mar 2000 19:09:21 -0500 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id QAA11165; Fri, 10 Mar 2000 16:13:18 -0800 (PST) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38C99032.2186B0AE@cisco.com> Date: Fri, 10 Mar 2000 19:15:46 -0500 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Subject: On D.1 X-cc: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Tom Taylor wrote > 21) D.1, first paragraph, last sentence specifies that "Responses must > be sent to the address and port from which the corresponding commands > were sent except if the response to a handoff or failover, in which case > the procedures of 11.5 apply". While this may be reasonable for > clustered systems, it does not seem reasonable for handoff between > non-clustered systems. To enable reliable delivery of this message, the > response should still be sent to the source of the request, but > otherwise the procedures of 11.5 applies. [[TomT]] Sorry, what's the difference between what you propose and what's there now? FSA: Lets say we have two MGCs, MA and MB controlling a gateway G. The way the current text reads, when MA wants to handoff G to MB and therefore sends a ServiceChange to G, G will have to send the response to MB rather than MA. How does MA know if the ServiceChange got lost ? It can only figure that out by having MB sending a confirmation to it which now dictates synchronization between MA and MB. Instead, it would seem better to have the response sent to MA. If synchronization is needed, it can still occur by the new ServiceChange G will send to MB, however it's no longer a requirement. -- Flemming -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 10 19:30:56 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28081 for ; Fri, 10 Mar 2000 19:30:52 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8C29CA90@standards.nortelnetworks.com>; Fri, 10 Mar 2000 19:26:34 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 84352 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Mar 2000 19:24:51 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E8C2B200@standards.nortelnetworks.com>; Fri, 10 Mar 2000 19:14:51 -0500 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id QAA13073; Fri, 10 Mar 2000 16:18:44 -0800 (PST) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38C99178.7EEA9137@cisco.com> Date: Fri, 10 Mar 2000 19:21:12 -0500 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Subject: On 7.2.5 X-cc: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Tom Taylor wrote: > > > 15) 7.2.5, fourth paragraph states that "Digitmap requested in an > > AuditValue command with TerminationID ALL returns all DigitMaps in > the > > gateway". Since digitmaps defined on specific terminations "shadow" > > digit maps defined on the root termination, it would seem that digit > > > maps defined on root should be excluded here (unless the reporting > > starts including the termination the digit map is defined on which > seems > > to be a more substantial change). > [[TomT]] Why can't the sentence mean what it says? A digit > map is > a name and a value. This paragraph doesn't say that the same digit > map is > reported multiple times, which I think is what you are implying. You're right, no issue. I was thinking that the same name could be used on a particular termination as well a the root termination, however that applies equally well between terminations. I guess you just audit accordingly instead of TerminationID ALL. -- Flemming -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 10 19:37:28 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25001 for ; Fri, 10 Mar 2000 19:20:18 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FD804BD0@standards.nortelnetworks.com>; Fri, 10 Mar 2000 19:15:26 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 84335 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 10 Mar 2000 19:14:13 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6CB01C80@standards.nortelnetworks.com>; Fri, 10 Mar 2000 19:04:13 -0500 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id QAA09338; Fri, 10 Mar 2000 16:08:11 -0800 (PST) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38C98EFF.614634D3@cisco.com> Date: Fri, 10 Mar 2000 19:10:39 -0500 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Subject: On 7.2.8 X-cc: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Tom Taylor wrote: > > > > 16) 7.2.8, Restart: As I have stated before, it is a mistake that > the > > gateway is not defined to be in a clean and well-defined state when > > "Restart" is issued. Consequently, I suggest that the sentence "the > > Terminations are assumed to now not be associated with any Context" > is > > put back in this defintion again. > [[TomT]] You were overruled by prevailing consensus. > Basically the > view is that the MGC is responsible for controlling the state of > terminations, aside from in-service/test/out-of-service. If it really > wants > to clear all contexts it has the tools to do that. Certainly not on the mailing list. There were only a few mails exchanged on this issue, in particular by Chip, Brian, and myself. I never got a response/resolution to the last one I sent out. -- Flemming -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sat Mar 11 11:58:55 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12782 for ; Sat, 11 Mar 2000 11:58:55 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8D728380@standards.nortelnetworks.com>; Sat, 11 Mar 2000 11:54:27 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 85123 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 11 Mar 2000 11:53:11 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FA7932A0@standards.nortelnetworks.com>; Sat, 11 Mar 2000 11:43:11 -0500 Received: from cisco.com (rtp-dial-2-140.cisco.com [10.83.96.140]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id IAA16097; Sat, 11 Mar 2000 08:47:06 -0800 (PST) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38CA7885.D55BE06A@cisco.com> Date: Sat, 11 Mar 2000 11:47:01 -0500 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Subject: On 7.1.4 X-cc: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Tom Taylor wrote: > > > 7) 7.1.14, last sentence in paragraph beginning with "The letter 'x' > is > > used as a wildcard..." specifies that "As a consequence of the thrid > > > timing rule above, inter-event timing while matching the dot symbol > uses > > the short timer by default." is incorrect. The grammar may continue > past > > the dot symbol implying the dot could only possibly produce a > partial > > match which furthermore implies that the short timer may not be the > > right one to use. The sentence should simply be removed. > [[TomT]] Agreed that the grammar may continue past the dot, > but > until you get that far you have an ambiguous situation -- you don't > know how > many events will be mapped into the dot. The sentence is correct > AFAIK. That's not entirely accurate, e.g. consider "x.#" Now, if what follows the dot has a non-empty intersection with what precedes the dot (ignoring timers), you have an ambigous situation. In that case you could then apply the short timer, or alternatively simply leave the timing rules undefined then (since you can always rewrite the digit map to avoid this, well at least in most cases). > > > > 8) 7.1.14, next paragraph specifies that "A timer specified > following a > > dot specifies inter-event timing for all events matching the dot as > well > > as for subsequent events". It's unclear why the timer couldn't > simply be > > put in front of the dot and thereby be consistent with digit map > timers > > in general. In the absence of a compelling argument the sentence > should > > simply be removed. > [[TomT]] Same problem as with the previous remark -- you > don't know > when you've gone past the dot until it's too late. If there is a > timer both > before and after the dot, a timer after the dot never gets used. It > may be > better just to say that, I suppose, leaving it up to the MGC to set a > timer > before the dot if it wants. You could have have "S.xL", but otherwise I agree. > > > > 9) 7.1.14, numbered list, item 4: The second sentence and the > last > > sentence seem to contradict each other. While absence of > long-duration > > may prevent a match from occurring, existence of long-duration > should > > not. Consequently, the second sentence is what should be modified. > [[TomT]] I assume you mean the last sentence of the > paragraph. You > will reach this case only if all of the alternatives specifying a > long-duration event at this point have been discarded. Thus duration > becomes irrelevant, but only after it has been taken into account in > the > cases where it mattered. OK, I think I understand now, however the rule then seems to be incorrect. Consider the digit map "Zx1 | x2" with input "Z1". The way I read rule 4, the second sentence would lead us to discard alternative "x2" which doesn't seem like the right thing to do, since "x2" doesn't prevent us from having a long event, right ? > > > > 10) 7.1.14, numbered list, item 5 specifies that "If exactly one > > candidate remains, a completion event is generated indicating an > > unambiguous match". This seems to imply that even a partial match > (as > > long as there is only one) will result in a digit map completion > event, > > which of course is incorrect. > [[TomT]] Good catch. This really is an error. We should > change > that to "If exactly one candidate remains and it is fully matched, > ..." > > > 11) 7.1.14, numbered list, item 5: It is entirely unclear why an > > event triggering a partial match is not reported as part of the > matched > > string. In the absence of a compelling argument, the triggering > event > > should be included in the string as it otherwise may be processed > twice, > > which is hardly what the user had in mind. > [[TomT]] I had it that way in the first place (with the > triggering > event distinguished by being placed in an "extra event" parameter) and > > consensus was to change it to what it is now. Have to overrule you on > this > one unless you get more support. Well, I think it would be more appropriate that those who argue against explain why. There's got to be a reasonable explanation here, or reviewing this stuff is a waste of everybody's time. > I'm also not clear how you get duplicate > processing -- the situation is logically equivalent to the triggering > event > (a non-matching digit) happening just after the digit completion event > has > been notified. Consider an IVR menu where input consists of two or more digits. For sake of argument, let's say the only valid choice is "12", and I erroneously enter "13". Upon entering "3" we get a mismatch and I probably hear a recording telling me that "13" is an invalid choice and I should try again. When digit map processing resumes for renewed input, "3" will now be processed and I get another mismatch. The event was processed twice which is the problem (a "process"/"discard" parameter in event handling would of course be a general cure for such problems, but alas, that was not to happen) > > > > 12) 7.1.14, second last paragraph states that "Regardles of whether > a > > digit map is activated, this form of event specification will cause > the > > individual events to be reported to the MGC as they are detected". > Some > > clarification is requested here. > [[TomT]] This paragraph gives the interpretation of e.g. the > "dd/*" > event specification. Using the example digit map which immediately > follows, > a dialled "1" will be reported immediately and also accumulated into > the > digit map. Of course, if EventBufferControl is set to LockStep, the > digit > map will never complete because a new Event Descriptor will be loaded > before > completion can be reported. (There is a corner case with a dialled > "0" and > short timer expiry before the new Event descriptor is loaded, but > let's not > go into that.) I can, to some extent, understand that, although I think this dual processing does little but underscore the lack of generality in the event handling scheme (interesting case when you have EventBufferControl off). At a bare minimum I think you should define that an event detected can at most match or be consumed by a single "event" specified in the EventsDescriptor. What I don't understand in the above sentence is, that it seems to imply that the name by which we refer to an event impacts the reporting of that event. With the current "dd" package, you may request digit map matching without by only requesting the "Digit Map Completion" event, i.e. do not request DTMF digits (correct ?). Thus I might define another package, call it "dd2" that only consists of this particular event. What the above sentence now implies is, that when I request "dd/ce", I will process according to the digit map, but when I request "dd/*", which can only expand to "dd/ce", I will report the digits invidually. Doesn't seem right. -- Flemming -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Mar 13 02:46:36 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00414 for ; Mon, 13 Mar 2000 02:46:36 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AA0540F0@standards.nortelnetworks.com>; Mon, 13 Mar 2000 2:41:42 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 85924 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Mar 2000 02:40:30 -0500 Received: from auemlsrv.firewall.lucent.com (192.11.223.161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7F627D40@standards.nortelnetworks.com>; Mon, 13 Mar 2000 2:40:30 -0500 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 CAA26405 for ; Mon, 13 Mar 2000 02:44:36 -0500 (EST) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id CAA26392 for ; Mon, 13 Mar 2000 02:44:35 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id IAA11449; Mon, 13 Mar 2000 08:44:34 +0100 (MET) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id IAA11440; Mon, 13 Mar 2000 08:44:25 +0100 (MET) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Original-CC: MEGACO@standards.nortelnetworks.com References: <5AC7D3F55147D311AA1700A0C99583ED2C3693@beex03.sgcs.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38CC9C51.46243391@lucent.com> Date: Mon, 13 Mar 2000 08:44:17 +0100 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: Comments on MEGACO protocol X-To: "Drage, Keith" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Keith, Most of the changes you request are ok. There's a couple that I don't know about: - (Re. 3) I thought that references to ITU Rec. have to be specific (i.e., including a date). I asked Glen, and he's not sure either. We'll check. - (Re. 5) What headers are missing according to you? The current ASN.1 starts with "MEDIA-GATEWAY-CONTROL DEFINITIONS AUTOMATIC TAGS::=". I checked the syntax with the OSS tools and didn't find a problem. - (Re. 6) I believe this was brought in through MSF and I never checked. Having looked up Q.2941.1 now, I agree that 4 octets is restrictive. John "Drage, Keith" wrote: > > Attached please find a number of editorial comments on the Geneva output > document, which we also understand is identical to the MEGACO last call > document. These points are not intended to be controversial. In the event > that discussion is required to resolve such a comment, then we will withdraw > the comment in order to allow the document to proceed. > > 1) Abbreviations. "BRI" is never used and therefore should be removed > from the list of abbreviations. > > 2) References. Q.724 is never used and should be removed. > > 3) References and annex C. Where a reference is only used in annex C, > we believe in general in most cases these should be undated (i.e. the latest > version of the referenced document applies). This in particular applies to > Q.931, Q. 2931, Q.763 where ITU-T SG11 have no intention of changing > codepoints to different values, but do reserve the right to add new values. > Surely the whole ethos of annex C is that new values do get automatically > incorporated. > > 4) References (and annex C if comment 3 not accepted). Some of the > dates are incorrect. Q.761-4 have a date of December 1999 as that was > decided last year. Q.2931 should reflect the date of the latest amendment > (4) which we believe is also December 1999. > > 5) Annex A. We could not find the module header, or an exports > statement, for the ASN.1. The module header is mandatory parts of the ASN.1, > and gives that module an object identifier, which is needed for inport to > anything else. > > 6) Annex C, C.8, generic identifier transport. We are not sure how you > fit this into four octets. Is there some subset of the generic identifier > transport information element that is being used? Various codings of this > information element get very, very long. > > 7) Annex C, C.9, ITC has a reference to a note 2, which is not in the > table. Is this a spurious inport from the referenced standard? If so, we > believe it can be deleted. > > 8) Annex C, C.9. References to Q.931 need to identify that the > references are to the encoding in the Bearer capability information element, > and not to the Low layer information element. The latter has identical > fields with the same code values, but has a more extensive range of values > assigned. This is because some values (particularly at layer 3) are only > defined for end user to addressed end user usage. I believe in H.248 only > the more restricted list in the Bearer capability information element would > be valid. > > Keith Drage > > > --------------------------------------------------------------- > > Keith Drage (keith.drage@siemenscomms.co.uk) > > Siemens Communications Limited, > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > --------------------------------------------------------------- > > Internet communications are not secure and therefore Siemens > > Communications Limited does not accept legal responsibility for the > > contents of this message. Any views or opinions presented are solely those > > of the author and do not necessarily represent those of Siemens > > Communications Limited unless otherwise specifically stated. > > > > -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Mar 13 11:10:00 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04684 for ; Mon, 13 Mar 2000 11:09:59 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FF0753E0@standards.nortelnetworks.com>; Mon, 13 Mar 2000 11:05:09 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 86226 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Mar 2000 11:04:58 -0500 Received: from pop-rocks.shoretel.com (208.163.34.3) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.929C76F0@standards.nortelnetworks.com>; Mon, 13 Mar 2000 10:54:58 -0500 Received: by pop-rocks.shoretel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 13 Mar 2000 07:59:04 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8D05.0E0DF794" Message-ID: <1A1B8F0BB483D311B1390050047448344026B6@pop-rocks.shoretel.com> Date: Mon, 13 Mar 2000 07:59:03 -0800 Reply-To: Jeff Ridley Sender: "Media Gateway Control (megaco)" From: Jeff Ridley Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt 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_01BF8D05.0E0DF794 Content-Type: text/plain; charset="iso-8859-1" Peter and Brian, I think I completely agree with the conclusions you both seem to have drawn. Focused applications of the protocol, such as the IP phone are a logical next step evolving the standardization efforts into specific implementation definitions that lead to compatibilities between systems and end points. As a systems vendor, I am anxious to see these definitions or profiles reach the point where, by following the minimal definition of the profile, the system can integrate support for different classes of endpoint with compatibility. This means we need to make a minimal selection where options exist and leave other choices for flexibility. If we all implement at least the minimum, our products inter-operate. To me, this should be one of the objectives of the profile. Jeff Ridley, Sr. Prod. Manager Shoreline Communications, Inc. -----Original Message----- From: Peter Blatherwick [mailto:blather@NORTELNETWORKS.COM] Sent: Thursday, March 09, 2000 7:48 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt Keith, list: I strongly agree with Brian and others here. I believe what we specifying by making minimum decisions on encoding and transport is absolutely required to make the application viable, does not affect other applications, and is exactly what profiles are intended to do. I do not think the protocol is deficient. Profiling is an extremely valuable aspect of the protocol, especially when combined with the flexibility and extensibility of packages. Profiles allow us to make critical decisions on the optional parts for specific applications, while not restricting how other applications work in any way. This both enables interoperability and reduces complexity for the specific application. And these decisions set the minimum requirement, not exclusive requirement. Such decisions are absolutely required for small scale, focused applications, of which IP Phone MG is just one example. As Brian suggests, we will clarify the wording in that area. -- Peter Blatherwick -----Original Message----- From: Rosen, Brian [SMTP:brosen@FORE.COM] Sent: 9 Mar, 2000 07:35 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt > > I'd go the other way. If a profile did NOT specify an > > encoding (or failed > > to > > specify a minimum for any other option the protocol offers, > > I'd say it was > > deficient. > > Is this not tantamount to saying the protocol is deficient as well? No, the protocol allows options. In this case, the option leads to interoperability problems because the MGC is not obligated to support both. Conformance to a profile should, IMO guarantee interoperability. Therefore, a profile must define at least a minimum for encoding. > > > > I'll agree that subsetting where the protocol does not define > > an option is > > inappropriate. > > > > I really think that requiring an MG to have both binary and text is > > unworkable > > Noone is proposing that an MG should implement both. All I > have suggested is > that an MG implementor should have the freedom to choose which they > implement. This is a consequence of the MGC decision to go > for SHOULD rather > than MUST. My understanding of that decision is that it is up > to the market > to decide, not a profile creator. The consequence of SHOULD is that incompatibility is a real possibility. A profile should eliminate this possibility. A profile is a specification of a minimum. Perhaps the authors could consider changing the wording to make that explicit. Any implementation could offer more than a profile specifies, and still be compatible. Brian > ------_=_NextPart_001_01BF8D05.0E0DF794 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: I-D ACTION:draft-ietf-megaco-ipphone-02.txt

P= eter and Brian,

<= ![if = !supportEmptyParas]> 

=

I= think I completely agree with the conclusions you both seem to have drawn.  Focused applications of the = protocol, such as the IP phone are a logical next step evolving the = standardization efforts into specific implementation definitions that lead to compatibilities = between systems and end points.

<= ![if = !supportEmptyParas]> 

=

A= s a systems vendor, I am anxious to see these definitions or profiles reach = the point where, by following the minimal definition of the profile, the = system can integrate support for different classes of endpoint with compatibility. = This means we need to make a minimal selection where options exist and leave = other choices for flexibility.  = If we all implement at least the minimum, our products inter-operate.  To me, this should be one of = the objectives of the profile.

<= ![if = !supportEmptyParas]> 

=

J= eff Ridley, Sr. Prod. Manager

S= horeline Communications, Inc.

<= ![if = !supportEmptyParas]> 

=

<= ![if = !supportEmptyParas]> 

=

<= ![if = !supportEmptyParas]> 

=

-----Original Message-----
From: Peter Blatherwick [mailto:blather@NORTELNETWORKS.COM]
Sent: Thursday, March = 09, 2000 7:48 AM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt

 

Keith, = list: =

I strongly = agree with Brian and others here.  I believe what we specifying by making = minimum decisions on encoding and transport is absolutely required to make the application viable, does not affect other applications, and is exactly = what profiles are intended to do.  =

I do not think = the protocol is deficient.  Profiling is an extremely valuable aspect = of the protocol, especially when combined with the flexibility and = extensibility of packages. 

Profiles allow = us to make critical decisions on the optional parts for specific = applications, while not restricting how other applications work in any way.  This both = enables interoperability and reduces complexity for the specific = application.  And these decisions set the minimum requirement, not exclusive = requirement.  Such decisions are absolutely required for small scale, focused = applications, of which IP Phone MG is just one example.  =

As Brian = suggests, we will clarify the wording in that area.   =

-- Peter = Blatherwick =

 =

-----Original Message-----
From:  <= /span> Rosen, Brian [SMTP:brosen@FORE.COM]
Sent:  <= /span> 9 Mar, 2000 07:35
To:  &nb= sp;  MEGACO@STANDARDS= .NORTELNETWORKS.COM
Subject: &nbs= p;      Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt

> > I'd = go the other way.  If a profile did NOT specify an
> > encoding (or failed
> > to
> > specify a minimum for any = other option the protocol offers,
> > I'd say it = was
> > deficient.
>
> Is this not tantamount to saying = the protocol is deficient as well?

No, the = protocol allows options.  In this case, the option leads to
interoperability problems because the = MGC is not obligated to support both.
Conformance to a profile should, IMO = guarantee interoperability.  Therefore,
a profile must define at least a minimum = for encoding. = =

 =

> = >
> > I'll agree that subsetting = where the protocol does not define
> > an option = is
> > = inappropriate.
> >
> > I really think that requiring = an MG to have both binary and text is
> > unworkable
>
> Noone is proposing that an MG = should implement both. All I
> have suggested = is
> that an MG implementor should have = the freedom to choose which they
> implement. This is a consequence of = the MGC decision to go
> for SHOULD = rather
> than MUST. My understanding of that decision is that it is up
> to the market
> to decide, not a profile = creator.
The consequence of SHOULD is that incompatibility is a real possibility.
A profile should eliminate this possibility.  A profile is a specification
of
a minimum.  Perhaps the authors = could consider changing the wording to make
that
explicit. Any implementation could offer = more than a profile specifies, and
still
be compatible.

Brian =

> =

------_=_NextPart_001_01BF8D05.0E0DF794-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Mar 13 17:52:25 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11724 for ; Mon, 13 Mar 2000 17:52:23 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4227CC30@standards.nortelnetworks.com>; Mon, 13 Mar 2000 17:47:53 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 86744 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 13 Mar 2000 17:47:27 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.32505110@standards.nortelnetworks.com>; Mon, 13 Mar 2000 17:47:27 -0500 Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id OAA20675 for ; Mon, 13 Mar 2000 14:51:32 -0800 (PST) X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.2.2.20000313172117.00a66de0@dogwood.cisco.com> Date: Mon, 13 Mar 2000 17:33:29 -0800 Reply-To: Chip Sharp Sender: "Media Gateway Control (megaco)" From: Chip Sharp Subject: Descriptor processing order To: MEGACO@STANDARDS.NORTELNETWORKS.COM Due to a previous question on event handling, I went through the output of SG16 (TD37) looking for text on the ordering of processing of descriptors. However, I could find no text in the document that describes in what order a MG or MGC should process descriptors. I was specifically wondering if the TerminationStateDescriptor was processed before the EventsDescriptor. This has implications in that the order of processing the value of the EventBufferControl parameter in the TerminationStateDescriptor and the EventsDescriptor will affect how events in the EventBuffer are processed. If TerminationStateDescriptor is processed first and EventBufferControl=Off (previous LockStep), then all events are discarded. If EventsDescriptor is processed first then at least one more event will be reported before the EventBuffer is flushed (ignoring the previous discussion as to whether this is desirable or not). It seems there may be any number of conditions like this that will depend on ordering of processing of descriptors in the command. Shouldn't there be some basic text in the spec that either specifies that the receiver of a command should process the descriptors in the order received or that the receiver can process them in any order desired? I prefer the former. The latter seems a little indeterminate. If there is already text of this nature in the document, please educate me as to its location. Thanks, Chip Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. -------------------------------------------------- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 14 03:38:04 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27517 for ; Tue, 14 Mar 2000 03:38:03 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0A151E40@standards.nortelnetworks.com>; Tue, 14 Mar 2000 3:33:18 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 87044 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Mar 2000 03:31:24 -0500 Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C468F790@standards.nortelnetworks.com>; Tue, 14 Mar 2000 3:31:21 -0500 Received: from ficon-tech.com (sphilip.india.ficon-tech.com [172.25.1.104]) by ficon-tech.com (8.9.3/8.8.7) with ESMTP id OAA18237 for ; Tue, 14 Mar 2000 14:00:03 +0530 (IST) (envelope-from sphilip@ficon-tech.com) X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: <38C79859.CB9D775E@ficon-tech.com> <38C8F28D.BC9CA1DD@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38CDF976.947CF35F@ficon-tech.com> Date: Tue, 14 Mar 2000 14:03:59 +0530 Reply-To: Shalini Philip Sender: "Media Gateway Control (megaco)" From: Shalini Philip Organization: Ficon Technology Subject: Re: [Fwd: Issues in V16 Draft] To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello John, Thanks for your response. Please find my comments embedded below. John Segers wrote: > Philip, > > Some response this time. Please see below. > > John > > Shalini Philip wrote: > > > > Hello all, > > I did not get any response to the earlier mail. So I am resending it. > > > > There is some clarification required on some of the latest changes > > in V16 draft. They are: > > > > 1. Section 11.2 on Cold Start says that : > > "Upon failure to obtain a reply, either from the Primary MGC, or a > > designated successor, the MG tries its pre-provisioned Secondary MGCs, > > in order. If the MG is unable to comply and it has established a > > transport connection to the MGC, it should close that connection. In any > > event, it should reject all subsequent requests from the MGC with Error > > 406 Version Not Supported." > > The situation of MG not being able to comply and sending errors of > > Version not supported, seems to be appropriate only for the case of > > Version negotiation failure and not as a general case. If MG is unable > > to comply due to some other reason, then the appropriate error should be > > returned. > > I checked back in my notes from the ITU meeting and before, and found > out that the offending text has been introduced in January (on the > 24th). I don't remember who suggested the change at that time. All I > remember is that there was a request to put in text about the error > message to be returned. Even for that purpose, the text looks strange > (what does "comply" refer to?). Suggestions? > The same text of MG not being able to comply due to version mismatch and sending the error of "Version not Supported" is already mentioned in Section 11.3. So IMO, the same text in Section 11.2 should be removed. > > > 2. In Section 7.2.5, it is clarified that if DigitMap is requested in an > > AuditValue command with TerminationID ALL, then all the digit maps > > defined in the gateway are returned. Since only the digit map names are > > getting returned here, it would not be possible to return those digit > > maps specified by MGC as part of the Event Descriptor, since they do not > > have names associated with them. > > For the case that one termination is addressed, the text reads > "DigitMapDescriptor returns the name or value of the current DigitMap > for the Termination.", which I interpreted as: if the DM has a name, the > name is returned, otherwise the value. I have to admit that the text is > not very clear, but your assumption that only names can be returned does > not seem right. > Looking at the ABNF, the Digit map descriptor requires Digit map name as a mandatory field. So how will DMs specified without a name be returned in the Audit Reply? > > > Regards, > > > > Shalini Philip > > Ficon Technology > > E-Mail : mailto:sphilip@ficon-tech.com > > Web : http://www.ficon-tech.com > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 306 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 -- Regards, Shalini Philip Ficon Technology E-Mail : mailto:sphilip@ficon-tech.com Web : http://www.ficon-tech.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 14 03:54:57 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04153 for ; Tue, 14 Mar 2000 03:54:57 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6BA93630@standards.nortelnetworks.com>; Tue, 14 Mar 2000 3:50:21 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 87076 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Mar 2000 03:48:26 -0500 Received: from btm4r4.alcatel.be by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C11D80A0@standards.nortelnetworks.com>; Tue, 14 Mar 2000 3:38:25 -0500 Received: from btmq9s.rc.bel.alcatel.be (root@btmq9s.rc.bel.alcatel.be [138.203.65.182]) by btm4r4.alcatel.be (8.9.1a/8.9.1) with ESMTP id JAA13248 for ; Tue, 14 Mar 2000 09:42:32 +0100 (MET) Received: from alcatel.be (bt00re [138.203.66.123]) by btmq9s.rc.bel.alcatel.be (8.8.8+Sun/8.8.8) with ESMTP id JAA15354 for ; Tue, 14 Mar 2000 09:42:26 +0100 (MET) X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38CDFB69.E9B7B558@alcatel.be> Date: Tue, 14 Mar 2000 09:42:17 +0100 Reply-To: Bart Van Doorselaer Sender: "Media Gateway Control (megaco)" From: Bart Van Doorselaer Organization: Alcatel Subject: FYI: new ID draft-bouwen-megaco-isdn-00.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit "Issues for Megaco - Sigtran Interworking in ISDN Access Gateways ", Jan Bouwen, Bart Van Doorselaer, Miek Dekeyser, 03/13/2000. (71198 bytes) http://www.ietf.org/internet-drafts/draft-bouwen-megaco-isdn-00.txt This document introduces the concept of an ISDN access gateway in the context of Megaco/H.248 and Sigtran protocols. For these ISDN access gateways, the ISDN B channels may be controlled by the Media Gateway Controller using megaco/H.248 while the User-to-Network signaling running over the D channels may be relayed to the Media Gateway Controller using either megaco/H.248 or the Sigtran protocols. The main issues involved are: * Megaco/H.248 and Sigtran protocols may interwork in different ways in ISDN access gateways, leaving room for non - interoperable solutions; * Megaco needs additional packages in order to support ISDN terminations in the ISDN access gateway; * A data service may be offered to ISDN users via the ISDN D- channel, introducing the need to introduce a NAS package for the D-channel. This document addresses these issues, proposes and explains different solutions and suggests best practice guideline for megaco / sigtran interworking in ISDN access gateways. Enjoy the reading. -- ____________________ Bart Van Doorselaer \ / _______________________________________________\ /____ \ / Research Engineer \ ALCATEL / DN2 Network Strategy Group Tel : +32 3 240 86 41 Francis Wellesplein 1 Fax : +32 3 240 99 32 B-2018 Antwerpen Belgium _____________________________________________________\ /__________ mailto:Bart.Van_Doorselaer@alcatel.be \ / \/ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 14 08:59:44 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20578 for ; Tue, 14 Mar 2000 08:59:43 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B6E66F80@standards.nortelnetworks.com>; Tue, 14 Mar 2000 8:53:06 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 87431 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Mar 2000 08:51:48 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.224254D0@standards.nortelnetworks.com>; Tue, 14 Mar 2000 8:41:47 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id IAA24780; Tue, 14 Mar 2000 08:45:55 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id IAA03403; Tue, 14 Mar 2000 08:45:56 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Tue, 14 Mar 2000 08:41:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF208AC2@whq-msgusr-02.fore.com> Date: Tue, 14 Mar 2000 08:45:27 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: new ID draft-bouwen-megaco-isdn-00.txt X-To: Bart Van Doorselaer X-cc: "SIGTRAN@standards.nortelnetworks.com" To: MEGACO@STANDARDS.NORTELNETWORKS.COM I've read through this I-D. It contains a wealth of information and ideas. I haven't seen you announce it on SIGTRAN, I believe you should, although since I copied this message to SIGTRAN, I seem to have done this for you :) If you propose this as a Megaco work item, I would suggest that most of the options be eliminated, leaving exactly one way to handle ISDN. I believe that any of the "carry Q.931 in Megaco" ideas are not appropriate - SCTP is of not much more complexity than TCP, and residential gateways should not have any difficulty in having to implement SCTP. Some other comments: 1. I have always been in favor of naming conventions. This one has the "ISDNterm" prefix. I find it completely useless. I don't think there is any advantage in having a naming convention for the trunk name, other than some kind of length limit and possible character set limit. The useful part is to name the B/D channels. 2. I'd be interested in the SIGTRAN groups opinion of how Q.921 Management is best accomplished. I rather doubt they would see it as a Megaco issue. Yet I have not seen these issues raised, and agree that there must be a way to do it. 3. I did like the association between SCTP session management and MEGACO control association management. I agree that we need this documented, and think you have a good starting point. 4. I have pondered whether the MGC ought to command the MG to establish SCTP associations for D channels, or whether the MG ought to just know it should do so and do it. You have given me more info to think about here. The D channel packet data problem is one I was dimly aware of, but had not really thought through. 5. I think an ISDN package will be required, and the audit capabilities you describe seem useful. I might want to rework how you are reporting them. This raises an issue I should know, but proclaim my ignorance for all to see: how does the PSTN assign a D channel, that is, who knows which channels are D channels, and how are they assigned? By provisioning, by convention, by inspection of bit patterns?. I'm most used to convention, but probably that is just the user side. 6. I think we should decide which end gets provisioned with things like Interface Identifier or Associated D-channel. I'd prefer this be an MGC thing, with the MG being told what to do if it has to be. You seem to assume it's the MG that is provisioned, and need to let the MGC know. This deserves discussion. 7. The layer 1 stuff is needed. Again I look for comments from the SIGTRAN folks - is this really something handled by Megaco? The coupling to ServiceChange is interesting, and I suspect useful to document. 8. I do think events are appropriate for Performance Grading. Similar events exist for other QoS problems. 9. Section 9.4 contains the gem of a new thread - on line provisioning changes, and how systems react. Again, I see this as something the OSS tells the MGC, not the MG, but others may have different opinions. Brian ------------ Brian Rosen, Principal Engineer Marconi (Formerly FORE Systems) 1000 FORE Drive, Warrendale, PA 15086 (724) 742-6826 mailto:brosen@eng.fore.com > -----Original Message----- > From: Bart Van Doorselaer [mailto:Bart.Van_Doorselaer@ALCATEL.BE] > Sent: Tuesday, March 14, 2000 3:42 AM > To: MEGACO@standards.nortelnetworks.com > Subject: FYI: new ID draft-bouwen-megaco-isdn-00.txt > > > "Issues for Megaco - Sigtran Interworking in ISDN Access > Gateways ", Jan > Bouwen, Bart Van Doorselaer, Miek Dekeyser, 03/13/2000. (71198 bytes) > > http://www.ietf.org/internet-drafts/draft-bouwen-megaco-isdn-00.txt > > This document introduces the concept of an ISDN access gateway in the > context of Megaco/H.248 and Sigtran protocols. For these ISDN access > gateways, the ISDN B channels may be controlled by the Media Gateway > Controller using megaco/H.248 while the User-to-Network signaling > running over the D channels may be relayed to the Media Gateway > Controller using either megaco/H.248 or the Sigtran > protocols. The main > issues involved are: > * Megaco/H.248 and Sigtran protocols may interwork in > different ways in > ISDN access gateways, leaving room for non - interoperable solutions; > * Megaco needs additional packages in order to support ISDN > terminations > in the ISDN access gateway; > * A data service may be offered to ISDN users via the ISDN D- channel, > introducing the need to introduce a NAS package for the D-channel. > This document addresses these issues, proposes and explains different > solutions and suggests best practice guideline for megaco / sigtran > interworking in ISDN access gateways. > > > Enjoy the reading. > > > -- > ____________________ > Bart Van Doorselaer \ / > _______________________________________________\ /____ > \ / > Research Engineer \ ALCATEL / > DN2 Network Strategy Group > Tel : +32 3 240 86 41 Francis Wellesplein 1 > Fax : +32 3 240 99 32 B-2018 Antwerpen Belgium > _____________________________________________________\ /__________ > mailto:Bart.Van_Doorselaer@alcatel.be \ / > \/ > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 14 09:34:52 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05031 for ; Tue, 14 Mar 2000 09:34:52 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E55AE260@standards.nortelnetworks.com>; Tue, 14 Mar 2000 9:30:11 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 87568 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Mar 2000 09:28:50 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4F04F900@standards.nortelnetworks.com>; Tue, 14 Mar 2000 9:18:50 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id JAA28626; Tue, 14 Mar 2000 09:22:57 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id JAA11031; Tue, 14 Mar 2000 09:22:31 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Tue, 14 Mar 2000 09:18:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF208AC4@whq-msgusr-02.fore.com> Date: Tue, 14 Mar 2000 09:22:00 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Descriptor processing order X-To: Chip Sharp To: MEGACO@STANDARDS.NORTELNETWORKS.COM Good point. I think we should add text that says descriptors are processed in the order they appear in the command, just like commands are processed in the order they appear in the action. Brian > -----Original Message----- > From: Chip Sharp [mailto:chsharp@cisco.com] > Sent: Monday, March 13, 2000 8:33 PM > To: MEGACO@standards.nortelnetworks.com > Subject: Descriptor processing order > > > Due to a previous question on event handling, I went through > the output of > SG16 (TD37) looking for text on the ordering of processing of > descriptors. > > However, I could find no text in the document that describes > in what order > a MG or MGC should process descriptors. I was specifically > wondering if > the TerminationStateDescriptor was processed before the > EventsDescriptor. This has implications in that the order of > processing > the value of the EventBufferControl parameter in the > TerminationStateDescriptor and the EventsDescriptor will > affect how events > in the EventBuffer are processed. > > If TerminationStateDescriptor is processed first and > EventBufferControl=Off > (previous LockStep), then all events are discarded. If > EventsDescriptor is > processed first then at least one more event will be reported > before the > EventBuffer is flushed (ignoring the previous discussion as > to whether this > is desirable or not). > > It seems there may be any number of conditions like this that > will depend > on ordering of processing of descriptors in the command. > > Shouldn't there be some basic text in the spec that either > specifies that > the receiver of a command should process the descriptors in the order > received or that the receiver can process them in any order > desired? I > prefer the former. The latter seems a little indeterminate. > > If there is already text of this nature in the document, > please educate me > as to its location. > > Thanks, > Chip > Support NetAid! http://www.netaid.org > -------------------------------------------------- > Chip Sharp Consulting Engineering > Cisco Systems Telco Bio-region > Reality - Love it or Leave it. > -------------------------------------------------- > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 14 09:57:00 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14277 for ; Tue, 14 Mar 2000 09:56:59 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FA2F7F40@standards.nortelnetworks.com>; Tue, 14 Mar 2000 9:52:15 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 87605 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Mar 2000 09:51:36 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E2C34030@standards.nortelnetworks.com>; Tue, 14 Mar 2000 9:51:35 -0500 Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id GAA20989; Tue, 14 Mar 2000 06:55:36 -0800 (PST) X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.2.2.20000314095121.00b1ade0@dogwood.cisco.com> Date: Tue, 14 Mar 2000 09:54:27 -0800 Reply-To: Chip Sharp Sender: "Media Gateway Control (megaco)" From: Chip Sharp Subject: Re: Descriptor processing order X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4FBEA8857476D311A03300204840E1CF208AC4@whq-msgusr-02.fore. com> I think this would resolve ambiguities and possible anomalous results on descriptor processing. If the MGC wants the MG to process the descriptors in a particular order, it would then have control. In the particular example I cited, I would assume that the MGC would always place TerminationStateDescriptor before EventsDescriptor (thus having EventBufferControl processed before the new EventsDescriptor); however, it would have the ability to reverse the order if it needed to. Chip At 09:22 AM 3/14/00 -0500, Rosen, Brian wrote: >Good point. I think we should add text that says >descriptors are processed in the order they appear >in the command, just like commands are processed >in the order they appear in the action. > >Brian > > > -----Original Message----- > > From: Chip Sharp [mailto:chsharp@cisco.com] > > Sent: Monday, March 13, 2000 8:33 PM > > To: MEGACO@standards.nortelnetworks.com > > Subject: Descriptor processing order > > > > > > Due to a previous question on event handling, I went through > > the output of > > SG16 (TD37) looking for text on the ordering of processing of > > descriptors. > > > > However, I could find no text in the document that describes > > in what order > > a MG or MGC should process descriptors. I was specifically > > wondering if > > the TerminationStateDescriptor was processed before the > > EventsDescriptor. This has implications in that the order of > > processing > > the value of the EventBufferControl parameter in the > > TerminationStateDescriptor and the EventsDescriptor will > > affect how events > > in the EventBuffer are processed. > > > > If TerminationStateDescriptor is processed first and > > EventBufferControl=Off > > (previous LockStep), then all events are discarded. If > > EventsDescriptor is > > processed first then at least one more event will be reported > > before the > > EventBuffer is flushed (ignoring the previous discussion as > > to whether this > > is desirable or not). > > > > It seems there may be any number of conditions like this that > > will depend > > on ordering of processing of descriptors in the command. > > > > Shouldn't there be some basic text in the spec that either > > specifies that > > the receiver of a command should process the descriptors in the order > > received or that the receiver can process them in any order > > desired? I > > prefer the former. The latter seems a little indeterminate. > > > > If there is already text of this nature in the document, > > please educate me > > as to its location. > > > > Thanks, > > Chip > > Support NetAid! http://www.netaid.org > > -------------------------------------------------- > > Chip Sharp Consulting Engineering > > Cisco Systems Telco Bio-region > > Reality - Love it or Leave it. > > -------------------------------------------------- > > Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. -------------------------------------------------- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 14 23:10:06 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA12264 for ; Tue, 14 Mar 2000 23:10:06 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C62C5FF0@standards.nortelnetworks.com>; Tue, 14 Mar 2000 23:05:22 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 88359 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 14 Mar 2000 23:04:16 -0500 Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.395AFC90@standards.nortelnetworks.com>; Tue, 14 Mar 2000 22:54:16 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id EAA25454; Wed, 15 Mar 2000 04:58:26 +0100 (MET) 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 EAA24771; Wed, 15 Mar 2000 04:58:25 +0100 (MET) Received: from ericsson.com (7-211.epa.ericsson.se [146.11.7.211]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA03955; Wed, 15 Mar 2000 04:58:21 +0100 (MET) X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: <5AC7D3F55147D311AA1700A0C99583ED2C3693@beex03.sgcs.co.uk> <38CC9C51.46243391@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38CF0A67.6F0DE010@ericsson.com> Date: Wed, 15 Mar 2000 04:58:31 +0100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Comments on MEGACO protocol X-To: John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Keith and John, Regarding 6 the intention was to use this as a binding reference (BNCid). Annex C should refer to octet 5 and above. For the BNCid the length as per the GIT would be 6 octets. Make sense? Cheers, Christian John Segers wrote: > > Keith, > > Most of the changes you request are ok. There's a couple that I don't > know about: > - (Re. 3) I thought that references to ITU Rec. have to be specific > (i.e., including a date). I asked Glen, and he's not sure either. > We'll check. > - (Re. 5) What headers are missing according to you? The current ASN.1 > starts with "MEDIA-GATEWAY-CONTROL DEFINITIONS AUTOMATIC TAGS::=". I > checked the syntax with the OSS tools and didn't find a problem. > - (Re. 6) I believe this was brought in through MSF and I never > checked. Having looked up Q.2941.1 now, I agree that 4 octets is > restrictive. > > John > > "Drage, Keith" wrote: > > > > Attached please find a number of editorial comments on the Geneva output > > document, which we also understand is identical to the MEGACO last call > > document. These points are not intended to be controversial. In the event > > that discussion is required to resolve such a comment, then we will withdraw > > the comment in order to allow the document to proceed. > > > > 1) Abbreviations. "BRI" is never used and therefore should be removed > > from the list of abbreviations. > > > > 2) References. Q.724 is never used and should be removed. > > > > 3) References and annex C. Where a reference is only used in annex C, > > we believe in general in most cases these should be undated (i.e. the latest > > version of the referenced document applies). This in particular applies to > > Q.931, Q. 2931, Q.763 where ITU-T SG11 have no intention of changing > > codepoints to different values, but do reserve the right to add new values. > > Surely the whole ethos of annex C is that new values do get automatically > > incorporated. > > > > 4) References (and annex C if comment 3 not accepted). Some of the > > dates are incorrect. Q.761-4 have a date of December 1999 as that was > > decided last year. Q.2931 should reflect the date of the latest amendment > > (4) which we believe is also December 1999. > > > > 5) Annex A. We could not find the module header, or an exports > > statement, for the ASN.1. The module header is mandatory parts of the ASN.1, > > and gives that module an object identifier, which is needed for inport to > > anything else. > > > > 6) Annex C, C.8, generic identifier transport. We are not sure how you > > fit this into four octets. Is there some subset of the generic identifier > > transport information element that is being used? Various codings of this > > information element get very, very long. > > > > 7) Annex C, C.9, ITC has a reference to a note 2, which is not in the > > table. Is this a spurious inport from the referenced standard? If so, we > > believe it can be deleted. > > > > 8) Annex C, C.9. References to Q.931 need to identify that the > > references are to the encoding in the Bearer capability information element, > > and not to the Low layer information element. The latter has identical > > fields with the same code values, but has a more extensive range of values > > assigned. This is because some values (particularly at layer 3) are only > > defined for end user to addressed end user usage. I believe in H.248 only > > the more restricted list in the Bearer capability information element would > > be valid. > > > > Keith Drage > > > > > --------------------------------------------------------------- > > > Keith Drage (keith.drage@siemenscomms.co.uk) > > > Siemens Communications Limited, > > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > > --------------------------------------------------------------- > > > Internet communications are not secure and therefore Siemens > > > Communications Limited does not accept legal responsibility for the > > > contents of this message. Any views or opinions presented are solely those > > > of the author and do not necessarily represent those of Siemens > > > Communications Limited unless otherwise specifically stated. > > > > > > > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 306 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 15 00:08:02 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03417 for ; Wed, 15 Mar 2000 00:08:02 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E4ABB630@standards.nortelnetworks.com>; Wed, 15 Mar 2000 0:03:29 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 88412 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 15 Mar 2000 00:01:44 -0500 Received: from web206.mail.yahoo.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.406E3AD0@standards.nortelnetworks.com>; Tue, 14 Mar 2000 23:51:44 -0500 Received: (qmail 17940 invoked by uid 60001); 15 Mar 2000 04:55:55 -0000 Received: from [205.188.199.152] by web206.mail.yahoo.com; Tue, 14 Mar 2000 20:55:55 PST MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-635723058-953096155=:10803" Message-ID: <20000315045555.17939.qmail@web206.mail.yahoo.com> Date: Tue, 14 Mar 2000 20:55:55 -0800 Reply-To: sayema kabir Sender: "Media Gateway Control (megaco)" From: sayema kabir Subject: HOME TYPIST WANTED [rawwk] X-cc: knfn1cxbsb@HOTBOT.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM --0-635723058-953096155=:10803 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Note: forwarded message attached. __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com --0-635723058-953096155=:10803 Content-Type: message/rfc822 Received: from [205.188.199.152] by web220.mail.yahoo.com; Tue, 14 Mar 2000 20:37:29 PST Date: Tue, 14 Mar 2000 20:37:29 -0800 (PST) From: sayema kabir Subject: More Information (Applying for Home Typist) To: homeworker@chicagooffice.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Length: 561 I am interested to work from home. I have Computer experience and also have computer and printer. Please give the details of the work. My name is Sayema Kabir. I am a Computer Consultant. I work from home. I am looking forward to work with you. Please let me know what will be the rate and when can I start. Hope to be hearing from you very soon through e-mail of you can call at 718-784-2360. Sincerely, Sayema Kabir __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com --0-635723058-953096155=:10803-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 15 03:48:23 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04784 for ; Wed, 15 Mar 2000 03:48:23 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A6C53660@standards.nortelnetworks.com>; Wed, 15 Mar 2000 3:43:39 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 88544 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 15 Mar 2000 03:41:47 -0500 Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FDD863C0@standards.nortelnetworks.com>; Wed, 15 Mar 2000 3:31:46 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id JAA18603; Wed, 15 Mar 2000 09:35:55 +0100 (MET) 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 JAA06525; Wed, 15 Mar 2000 09:35:53 +0100 (MET) Received: from ericsson.com (7-211.epa.ericsson.se [146.11.7.211]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id JAA04628; Wed, 15 Mar 2000 09:35:50 +0100 (MET) X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: <4.2.2.20000314095121.00b1ade0@dogwood.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38CF322F.C9BB3964@ericsson.com> Date: Wed, 15 Mar 2000 07:48:15 +0100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Descriptor processing order X-To: Chip Sharp To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Chip and Brian, Sounds like a good idea it what I've always assumed (but as we've found out several times with this protocol, assumptions are dangerous). Is this something for the implementor's guide or an error fix? Cheers, Christian Chip Sharp wrote: > > I think this would resolve ambiguities and possible anomalous results on > descriptor processing. If the MGC wants the MG to process the descriptors > in a particular order, it would then have control. > > In the particular example I cited, I would assume that the MGC would always > place TerminationStateDescriptor before EventsDescriptor (thus having > EventBufferControl processed before the new EventsDescriptor); however, it > would have the ability to reverse the order if it needed to. > > Chip > > At 09:22 AM 3/14/00 -0500, Rosen, Brian wrote: > >Good point. I think we should add text that says > >descriptors are processed in the order they appear > >in the command, just like commands are processed > >in the order they appear in the action. > > > >Brian > > > > > -----Original Message----- > > > From: Chip Sharp [mailto:chsharp@cisco.com] > > > Sent: Monday, March 13, 2000 8:33 PM > > > To: MEGACO@standards.nortelnetworks.com > > > Subject: Descriptor processing order > > > > > > > > > Due to a previous question on event handling, I went through > > > the output of > > > SG16 (TD37) looking for text on the ordering of processing of > > > descriptors. > > > > > > However, I could find no text in the document that describes > > > in what order > > > a MG or MGC should process descriptors. I was specifically > > > wondering if > > > the TerminationStateDescriptor was processed before the > > > EventsDescriptor. This has implications in that the order of > > > processing > > > the value of the EventBufferControl parameter in the > > > TerminationStateDescriptor and the EventsDescriptor will > > > affect how events > > > in the EventBuffer are processed. > > > > > > If TerminationStateDescriptor is processed first and > > > EventBufferControl=Off > > > (previous LockStep), then all events are discarded. If > > > EventsDescriptor is > > > processed first then at least one more event will be reported > > > before the > > > EventBuffer is flushed (ignoring the previous discussion as > > > to whether this > > > is desirable or not). > > > > > > It seems there may be any number of conditions like this that > > > will depend > > > on ordering of processing of descriptors in the command. > > > > > > Shouldn't there be some basic text in the spec that either > > > specifies that > > > the receiver of a command should process the descriptors in the order > > > received or that the receiver can process them in any order > > > desired? I > > > prefer the former. The latter seems a little indeterminate. > > > > > > If there is already text of this nature in the document, > > > please educate me > > > as to its location. > > > > > > Thanks, > > > Chip > > > Support NetAid! http://www.netaid.org > > > -------------------------------------------------- > > > Chip Sharp Consulting Engineering > > > Cisco Systems Telco Bio-region > > > Reality - Love it or Leave it. > > > -------------------------------------------------- > > > > > Support NetAid! http://www.netaid.org > -------------------------------------------------- > Chip Sharp Consulting Engineering > Cisco Systems Telco Bio-region > Reality - Love it or Leave it. > -------------------------------------------------- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 15 04:55:43 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27380 for ; Wed, 15 Mar 2000 04:55:42 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0A944600@standards.nortelnetworks.com>; Wed, 15 Mar 2000 4:50:52 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 88692 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 15 Mar 2000 04:50:45 -0500 Received: from mail-dns1-nj.dialogic.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.060D8560@standards.nortelnetworks.com>; Wed, 15 Mar 2000 4:50:45 -0500 Received: from mail4.dialogic.com ([146.152.6.40]) by mail-dns1-nj.dialogic.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.11 1999/11/10 17:27:15 spurcell Exp $) with ESMTP id JAA20533 for ; Wed, 15 Mar 2000 09:56:33 GMT Received: from exchange3nj.dialogic.com (mailnj.dialogic.com [146.152.3.18]) by mail4.dialogic.com (PMDF V5.2-31 #40816) with ESMTP id <0FRG00J79JJFTY@mail4.dialogic.com> for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 15 Mar 2000 04:54:51 -0500 (EST) Received: from stieglitz (test-addr.dialogic.com [146.152.2.63]) by exchange3nj.dialogic.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id G4AQV784; Wed, 15 Mar 2000 04:54:48 -0500 X-Sender: magnells@exchange1nj.dialogic.com MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <4.2.2.20000314095121.00b1ade0@dogwood.cisco.com> Message-ID: <3.0.3.32.20000315045440.007842c8@exchange1nj.dialogic.com> Date: Wed, 15 Mar 2000 04:54:40 -0500 Reply-To: Steven Magnell Sender: "Media Gateway Control (megaco)" From: Steven Magnell Subject: Re: Descriptor processing order To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <38CF322F.C9BB3964@ericsson.com> Content-Transfer-Encoding: 7BIT This discussion exposes a syntactic difference between the binary and text encodings of the protocol. The binary encoding describes the list of descriptors in the Add/Move/Modify commands as a SEQUENCE which follows the order given by the abstract API descriptions of the commands. The text encoding, on the other hand, specifies only a list of parameters where the parameters are the separately defined as the descriptors, allowing variations in the order of descriptors. Chip's expectation that the order of descriptors can be reversed in order to affect the order of processing is only possible using the text encoding. Given this difference either the binary encoding syntax should be changed or the order of descriptor interpretation should follow the order given in the abstract API. steve At 07:48 AM 3/15/00 +0100, Christian Groves wrote: >G'Day Chip and Brian, > >Sounds like a good idea it what I've always assumed (but as we've found >out several times with this protocol, assumptions are dangerous). Is >this something for the implementor's guide or an error fix? > >Cheers, Christian > >Chip Sharp wrote: >> >> I think this would resolve ambiguities and possible anomalous results on >> descriptor processing. If the MGC wants the MG to process the descriptors >> in a particular order, it would then have control. >> >> In the particular example I cited, I would assume that the MGC would always >> place TerminationStateDescriptor before EventsDescriptor (thus having >> EventBufferControl processed before the new EventsDescriptor); however, it >> would have the ability to reverse the order if it needed to. >> >> Chip >> >> At 09:22 AM 3/14/00 -0500, Rosen, Brian wrote: >> >Good point. I think we should add text that says >> >descriptors are processed in the order they appear >> >in the command, just like commands are processed >> >in the order they appear in the action. >> > >> >Brian >> > >> > > -----Original Message----- >> > > From: Chip Sharp [mailto:chsharp@cisco.com] >> > > Sent: Monday, March 13, 2000 8:33 PM >> > > To: MEGACO@standards.nortelnetworks.com >> > > Subject: Descriptor processing order >> > > >> > > >> > > Due to a previous question on event handling, I went through >> > > the output of >> > > SG16 (TD37) looking for text on the ordering of processing of >> > > descriptors. >> > > >> > > However, I could find no text in the document that describes >> > > in what order >> > > a MG or MGC should process descriptors. I was specifically >> > > wondering if >> > > the TerminationStateDescriptor was processed before the >> > > EventsDescriptor. This has implications in that the order of >> > > processing >> > > the value of the EventBufferControl parameter in the >> > > TerminationStateDescriptor and the EventsDescriptor will >> > > affect how events >> > > in the EventBuffer are processed. >> > > >> > > If TerminationStateDescriptor is processed first and >> > > EventBufferControl=Off >> > > (previous LockStep), then all events are discarded. If >> > > EventsDescriptor is >> > > processed first then at least one more event will be reported >> > > before the >> > > EventBuffer is flushed (ignoring the previous discussion as >> > > to whether this >> > > is desirable or not). >> > > >> > > It seems there may be any number of conditions like this that >> > > will depend >> > > on ordering of processing of descriptors in the command. >> > > >> > > Shouldn't there be some basic text in the spec that either >> > > specifies that >> > > the receiver of a command should process the descriptors in the order >> > > received or that the receiver can process them in any order >> > > desired? I >> > > prefer the former. The latter seems a little indeterminate. >> > > >> > > If there is already text of this nature in the document, >> > > please educate me >> > > as to its location. >> > > >> > > Thanks, >> > > Chip >> > > Support NetAid! http://www.netaid.org >> > > -------------------------------------------------- >> > > Chip Sharp Consulting Engineering >> > > Cisco Systems Telco Bio-region >> > > Reality - Love it or Leave it. >> > > -------------------------------------------------- >> > > >> >> Support NetAid! http://www.netaid.org >> -------------------------------------------------- >> Chip Sharp Consulting Engineering >> Cisco Systems Telco Bio-region >> Reality - Love it or Leave it. >> -------------------------------------------------- > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 15 04:58:36 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28294 for ; Wed, 15 Mar 2000 04:58:36 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.52E7E600@standards.nortelnetworks.com>; Wed, 15 Mar 2000 4:52:54 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 88705 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 15 Mar 2000 04:52:11 -0500 Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3855D5E0@standards.nortelnetworks.com>; Wed, 15 Mar 2000 4:52:09 -0500 Received: from ficon-tech.com (skylab.india.ficon-tech.com [172.25.2.100]) by ficon-tech.com (8.9.3/8.8.7) with ESMTP id PAA59366 for ; Wed, 15 Mar 2000 15:20:56 +0530 (IST) (envelope-from vsalota@ficon-tech.com) X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38CF5E6F.783DB715@ficon-tech.com> Date: Wed, 15 Mar 2000 15:27:03 +0530 Reply-To: Vikas Salota Sender: "Media Gateway Control (megaco)" From: Vikas Salota Subject: sub-list value type for package stats To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi ! There seems to be a discrepancy in the possible package stats values type as defined in Sec 12.2 and the ABNF. Sec 12.2 suggests that package stats can be of type sub-list but the ABNF does not support sub-list values for stats values. To support the sub-list type stats values, the ABNF definition statisticsParameter = pkgdName EQUAL VALUE should be changed to statisticsParameter = pkgdName EQUAL (VALUE / LSBRKT VALUE *(COMMA VALUE) RSBRKT ) Although similar change would have been necessitated in the definition of parmValue too if it were not for the support of over-specification of these values. Since due to possible over specification of these values, sub-list type of values for package signals and events can be supported with the current definition of parmValue. But then we can't over specify package events/signals of type sub-list because a list of values for these type of events/signals would always be interpreted as the sub-list value. If we have to support over specification of sub-list typed events/signals, the definition of parmValue should be changed to support list of sub-list values too. with regards Vikas Salota From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 15 08:53:09 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28981 for ; Wed, 15 Mar 2000 08:53:08 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3C3EF3F0@standards.nortelnetworks.com>; Wed, 15 Mar 2000 8:48:29 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 89038 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 15 Mar 2000 08:47:14 -0500 Received: from auemail2.firewall.lucent.com (192.11.223.163) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0F8D4D70@standards.nortelnetworks.com>; Wed, 15 Mar 2000 8:47:14 -0500 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 IAA02365 for ; Wed, 15 Mar 2000 08:51:26 -0500 (EST) 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 IAA02345 for ; Wed, 15 Mar 2000 08:51:25 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA18463; Wed, 15 Mar 2000 14:51:21 +0100 (MET) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA18459; Wed, 15 Mar 2000 14:51:20 +0100 (MET) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <38C79859.CB9D775E@ficon-tech.com> <38C8F28D.BC9CA1DD@lucent.com> <38C91CEF.8C7BEB8A@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38CF954F.35898922@lucent.com> Date: Wed, 15 Mar 2000 14:51:11 +0100 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: [Fwd: Issues in V16 Draft] To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Flemming Andreasen wrote: [snip] > > > 1. Section 11.2 on Cold Start says that : > > > "Upon failure to obtain a reply, either from the Primary MGC, or a > > > designated successor, the MG tries its pre-provisioned Secondary MGCs, > > > in order. If the MG is unable to comply and it has established a > > > transport connection to the MGC, it should close that connection. In any > > > event, it should reject all subsequent requests from the MGC with Error > > > 406 Version Not Supported." > > > The situation of MG not being able to comply and sending errors of > > > Version not supported, seems to be appropriate only for the case of > > > Version negotiation failure and not as a general case. If MG is unable > > > to comply due to some other reason, then the appropriate error should be > > > returned. > > > > I checked back in my notes from the ITU meeting and before, and found > > out that the offending text has been introduced in January (on the > > 24th). I don't remember who suggested the change at that time. All I > > remember is that there was a request to put in text about the error > > message to be returned. Even for that purpose, the text looks strange > > (what does "comply" refer to?). Suggestions? > > I made the same comment and I think you are looking at Section 11.3, not 11.2. The > change got introduced in v16, and when you look at a similar change made in Section > 11.3 it seems like a simple editorial mistake. If it's not, discussion is clearly > needed. I agree that it is better to remove the text than to leave it in. > > > 2. In Section 7.2.5, it is clarified that if DigitMap is requested in an > > > AuditValue command with TerminationID ALL, then all the digit maps > > > defined in the gateway are returned. Since only the digit map names are > > > getting returned here, it would not be possible to return those digit > > > maps specified by MGC as part of the Event Descriptor, since they do not > > > have names associated with them. > > > > For the case that one termination is addressed, the text reads > > "DigitMapDescriptor returns the name or value of the current DigitMap > > for the Termination.", which I interpreted as: if the DM has a name, the > > name is returned, otherwise the value. I have to admit that the text is > > not very clear, but your assumption that only names can be returned does > > not seem right. > > > > There is however another issue of shadowing between the root termination and other > terminations. I think that the digit maps defined on the root termination should only be returned as being defined on root. There does not seem to be a need to return the same digit map for all individual terminations too. John -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 15 09:05:12 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03992 for ; Wed, 15 Mar 2000 09:05:12 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EB91CE80@standards.nortelnetworks.com>; Wed, 15 Mar 2000 9:00:33 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 89085 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 15 Mar 2000 08:59:57 -0500 Received: from auemail2.firewall.lucent.com (192.11.223.163) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D6772090@standards.nortelnetworks.com>; Wed, 15 Mar 2000 8:59:57 -0500 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 JAA18509 for ; Wed, 15 Mar 2000 09:04:10 -0500 (EST) 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 JAA18478 for ; Wed, 15 Mar 2000 09:04:09 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA20252; Wed, 15 Mar 2000 15:04:07 +0100 (MET) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA20237; Wed, 15 Mar 2000 15:04:06 +0100 (MET) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <38C79859.CB9D775E@ficon-tech.com> <38C8F28D.BC9CA1DD@lucent.com> <38CDF976.947CF35F@ficon-tech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38CF9848.522E59D4@lucent.com> Date: Wed, 15 Mar 2000 15:03:52 +0100 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: [Fwd: Issues in V16 Draft] To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Shalini Philip wrote: [snip] > > > 1. Section 11.2 on Cold Start says that : > > > "Upon failure to obtain a reply, either from the Primary MGC, or a > > > designated successor, the MG tries its pre-provisioned Secondary MGCs, > > > in order. If the MG is unable to comply and it has established a > > > transport connection to the MGC, it should close that connection. In any > > > event, it should reject all subsequent requests from the MGC with Error > > > 406 Version Not Supported." > > > The situation of MG not being able to comply and sending errors of > > > Version not supported, seems to be appropriate only for the case of > > > Version negotiation failure and not as a general case. If MG is unable > > > to comply due to some other reason, then the appropriate error should be > > > returned. > > > > I checked back in my notes from the ITU meeting and before, and found > > out that the offending text has been introduced in January (on the > > 24th). I don't remember who suggested the change at that time. All I > > remember is that there was a request to put in text about the error > > message to be returned. Even for that purpose, the text looks strange > > (what does "comply" refer to?). Suggestions? > > > > The same text of MG not being able to comply due to version mismatch and sending > the error of "Version not Supported" is already mentioned in Section 11.3. So IMO, > the same text in Section 11.2 should be removed. I agree with you and Flemming that this is the best thing to do. > > > 2. In Section 7.2.5, it is clarified that if DigitMap is requested in an > > > AuditValue command with TerminationID ALL, then all the digit maps > > > defined in the gateway are returned. Since only the digit map names are > > > getting returned here, it would not be possible to return those digit > > > maps specified by MGC as part of the Event Descriptor, since they do not > > > have names associated with them. > > > > For the case that one termination is addressed, the text reads > > "DigitMapDescriptor returns the name or value of the current DigitMap > > for the Termination.", which I interpreted as: if the DM has a name, the > > name is returned, otherwise the value. I have to admit that the text is > > not very clear, but your assumption that only names can be returned does > > not seem right. > > > > Looking at the ABNF, the Digit map descriptor requires Digit map name as a > mandatory field. So how will DMs specified without a name be returned in the Audit > Reply? Good point. There doesn't seem to be a way of returning only a value (neither in ABNF, nor in ASN.1). It seems that we have to change the ABNF and ASN.1 to something like digitMapDescriptor = DigitMapToken EQUAL ( (LBRKT digitMapValue RBRKT) / (digitMapname [ LBRKT digitMapValue RBRKT ]) ) and DigitMapDescriptor ::= SEQUENCE { digitMapName DigitMapName OPTIONAL, digitMapValue DigitMapValue OPTIONAL } Comments? John -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 15 09:15:20 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08010 for ; Wed, 15 Mar 2000 09:15:19 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0B9705A0@standards.nortelnetworks.com>; Wed, 15 Mar 2000 9:08:36 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 89082 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 15 Mar 2000 09:06:44 -0500 Received: from drawbridge.ascend.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6270FA90@standards.nortelnetworks.com>; Wed, 15 Mar 2000 8:56:42 -0500 Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id FAA26234; Wed, 15 Mar 2000 05:54:22 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 15 Mar 2000 14:00:51 UT Received: from porky (porky.ascend.com [192.207.23.83]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id GAA05750; Wed, 15 Mar 2000 06:00:50 -0800 (PST) Received: from ascend.com by ascend.com X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.2.2.20000315055718.00b03b90@porky> Date: Wed, 15 Mar 2000 06:01:47 -0800 Reply-To: Matt Holdrege Sender: "Media Gateway Control (megaco)" From: Matt Holdrege Subject: Re: FYI: new ID draft-bouwen-megaco-isdn-00.txt X-To: Bart Van Doorselaer X-cc: SIGTRAN@STANDARDS.NORTELNETWORKS.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <38CDFB69.E9B7B558@alcatel.be> I spoke to Jan today and I ought to fill in everyone else. First of all, at the last design team conference call I was able to finally express verbally my reasons for putting a TCP option into the UA's. We agreed to put a small note about TCP in the introduction with a pointer to a TCP section later in the documents. The bottom line is that SCTP is the main transport for the UA's, but TCP is a viable option in *certain* scenarios. You'll all be able to review this text in the rev's following Adelaide. So with the ability to do TCP and the seemingly best choice of the SIGTRAN IUA to transport many of us are recommending against ISDN backhaul with MEGACO. It's obviously better to have one choice in this case. At 09:42 AM 3/14/00 +0100, Bart Van Doorselaer wrote: >"Issues for Megaco - Sigtran Interworking in ISDN Access Gateways ", Jan >Bouwen, Bart Van Doorselaer, Miek Dekeyser, 03/13/2000. (71198 bytes) > >http://www.ietf.org/internet-drafts/draft-bouwen-megaco-isdn-00.txt > >This document introduces the concept of an ISDN access gateway in the >context of Megaco/H.248 and Sigtran protocols. For these ISDN access >gateways, the ISDN B channels may be controlled by the Media Gateway >Controller using megaco/H.248 while the User-to-Network signaling >running over the D channels may be relayed to the Media Gateway >Controller using either megaco/H.248 or the Sigtran protocols. The main >issues involved are: >* Megaco/H.248 and Sigtran protocols may interwork in different ways in >ISDN access gateways, leaving room for non - interoperable solutions; >* Megaco needs additional packages in order to support ISDN terminations >in the ISDN access gateway; >* A data service may be offered to ISDN users via the ISDN D- channel, >introducing the need to introduce a NAS package for the D-channel. >This document addresses these issues, proposes and explains different >solutions and suggests best practice guideline for megaco / sigtran >interworking in ISDN access gateways. > > >Enjoy the reading. > > >-- > ____________________ >Bart Van Doorselaer \ / >_______________________________________________\ /____ > \ / >Research Engineer \ ALCATEL / >DN2 Network Strategy Group >Tel : +32 3 240 86 41 Francis Wellesplein 1 >Fax : +32 3 240 99 32 B-2018 Antwerpen Belgium >_____________________________________________________\ /__________ >mailto:Bart.Van_Doorselaer@alcatel.be \ / > \/ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 15 09:25:21 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11454 for ; Wed, 15 Mar 2000 09:25:21 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BCBF8A90@standards.nortelnetworks.com>; Wed, 15 Mar 2000 9:20:42 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 89203 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 15 Mar 2000 09:19:39 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.96C28130@standards.nortelnetworks.com>; Wed, 15 Mar 2000 9:19:39 -0500 Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id GAA08175; Wed, 15 Mar 2000 06:23:44 -0800 (PST) X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 References: <38CF322F.C9BB3964@ericsson.com> <4.2.2.20000314095121.00b1ade0@dogwood.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.2.2.20000315081224.00aa75e0@dogwood.cisco.com> Date: Wed, 15 Mar 2000 08:53:41 -0800 Reply-To: Chip Sharp Sender: "Media Gateway Control (megaco)" From: Chip Sharp Subject: Re: Descriptor processing order X-To: Steven Magnell To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <3.0.3.32.20000315045440.007842c8@exchange1nj.dialogic.com> I hadn't thought of it before, but these are two separate issues. The first issue as noted by Steve is that the text encoding doesn't specify an order on the descriptors in the command. This seems to apply only to the text encoding since the binary encoding does restrict order. The second issue is the order of processing, regardless of order of descriptors in the command. This issue applies to both text and binary encoding. There seems to be an agreement on some basic text to clarify the second issue (process descriptors in order of receipt). In fact I would classify this as "errata". The first issue is much thornier. I don't really have an opinion one way or other. Chip P.S. Enjoy Adelaide. I won't make it this time. At 04:54 AM 3/15/00 -0500, Steven Magnell wrote: >This discussion exposes a syntactic difference between the binary and text >encodings of the protocol. The binary encoding describes the list of >descriptors in the Add/Move/Modify commands as a SEQUENCE which follows the >order given by the abstract API descriptions of the commands. The text >encoding, on the other hand, specifies only a list of parameters where the >parameters are the separately defined as the descriptors, allowing >variations in the order of descriptors. > >Chip's expectation that the order of descriptors can be reversed in order >to affect the order of processing is only possible using the text encoding. > >Given this difference either the binary encoding syntax should be changed >or the order of descriptor interpretation should follow the order given in >the abstract API. > >steve > >At 07:48 AM 3/15/00 +0100, Christian Groves wrote: > >G'Day Chip and Brian, > > > >Sounds like a good idea it what I've always assumed (but as we've found > >out several times with this protocol, assumptions are dangerous). Is > >this something for the implementor's guide or an error fix? > > > >Cheers, Christian > > > >Chip Sharp wrote: > >> > >> I think this would resolve ambiguities and possible anomalous results on > >> descriptor processing. If the MGC wants the MG to process the descriptors > >> in a particular order, it would then have control. > >> > >> In the particular example I cited, I would assume that the MGC would > always > >> place TerminationStateDescriptor before EventsDescriptor (thus having > >> EventBufferControl processed before the new EventsDescriptor); however, it > >> would have the ability to reverse the order if it needed to. > >> > >> Chip > >> > >> At 09:22 AM 3/14/00 -0500, Rosen, Brian wrote: > >> >Good point. I think we should add text that says > >> >descriptors are processed in the order they appear > >> >in the command, just like commands are processed > >> >in the order they appear in the action. > >> > > >> >Brian > >> > > >> > > -----Original Message----- > >> > > From: Chip Sharp [mailto:chsharp@cisco.com] > >> > > Sent: Monday, March 13, 2000 8:33 PM > >> > > To: MEGACO@standards.nortelnetworks.com > >> > > Subject: Descriptor processing order > >> > > > >> > > > >> > > Due to a previous question on event handling, I went through > >> > > the output of > >> > > SG16 (TD37) looking for text on the ordering of processing of > >> > > descriptors. > >> > > > >> > > However, I could find no text in the document that describes > >> > > in what order > >> > > a MG or MGC should process descriptors. I was specifically > >> > > wondering if > >> > > the TerminationStateDescriptor was processed before the > >> > > EventsDescriptor. This has implications in that the order of > >> > > processing > >> > > the value of the EventBufferControl parameter in the > >> > > TerminationStateDescriptor and the EventsDescriptor will > >> > > affect how events > >> > > in the EventBuffer are processed. > >> > > > >> > > If TerminationStateDescriptor is processed first and > >> > > EventBufferControl=Off > >> > > (previous LockStep), then all events are discarded. If > >> > > EventsDescriptor is > >> > > processed first then at least one more event will be reported > >> > > before the > >> > > EventBuffer is flushed (ignoring the previous discussion as > >> > > to whether this > >> > > is desirable or not). > >> > > > >> > > It seems there may be any number of conditions like this that > >> > > will depend > >> > > on ordering of processing of descriptors in the command. > >> > > > >> > > Shouldn't there be some basic text in the spec that either > >> > > specifies that > >> > > the receiver of a command should process the descriptors in the order > >> > > received or that the receiver can process them in any order > >> > > desired? I > >> > > prefer the former. The latter seems a little indeterminate. > >> > > > >> > > If there is already text of this nature in the document, > >> > > please educate me > >> > > as to its location. > >> > > > >> > > Thanks, > >> > > Chip > >> > > Support NetAid! http://www.netaid.org > >> > > -------------------------------------------------- > >> > > Chip Sharp Consulting Engineering > >> > > Cisco Systems Telco Bio-region > >> > > Reality - Love it or Leave it. > >> > > -------------------------------------------------- > >> > > > >> > >> Support NetAid! http://www.netaid.org > >> -------------------------------------------------- > >> Chip Sharp Consulting Engineering > >> Cisco Systems Telco Bio-region > >> Reality - Love it or Leave it. > >> -------------------------------------------------- > > Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. -------------------------------------------------- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 15 10:14:07 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02550 for ; Wed, 15 Mar 2000 10:14:05 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.74DF8FC0@standards.nortelnetworks.com>; Wed, 15 Mar 2000 10:08:48 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 89268 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 15 Mar 2000 10:06:51 -0500 Received: from hoemail2.firewall.lucent.com (192.11.226.163) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2E93A6A0@standards.nortelnetworks.com>; Wed, 15 Mar 2000 10:06:50 -0500 Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA20971 for ; Wed, 15 Mar 2000 10:11:03 -0500 (EST) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA20954 for ; Wed, 15 Mar 2000 10:11:02 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA04231; Wed, 15 Mar 2000 16:11:00 +0100 (MET) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA04221; Wed, 15 Mar 2000 16:10:59 +0100 (MET) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <5AC7D3F55147D311AA1700A0C99583ED2C3693@beex03.sgcs.co.uk> <38CC9C51.46243391@lucent.com> <38CF0A67.6F0DE010@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38CFA7F9.6101E5AB@lucent.com> Date: Wed, 15 Mar 2000 16:10:49 +0100 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: Comments on MEGACO protocol To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Christian, I believe it makes sense when it is used for binding reference. If we only use octet 5 and above, and only use the GIT parameter for this specific case, we should rethink the name of the parameter. Using GIT with a reference to Q.2941.1 will undoubtedly lead to confusion. John Christian Groves wrote: > > G'Day Keith and John, > > Regarding 6 the intention was to use this as a binding reference > (BNCid). Annex C should refer to octet 5 and above. For the BNCid the > length as per the GIT would be 6 octets. Make sense? > > Cheers, Christian > > John Segers wrote: > > > > Keith, > > > > Most of the changes you request are ok. There's a couple that I don't > > know about: > > - (Re. 3) I thought that references to ITU Rec. have to be specific > > (i.e., including a date). I asked Glen, and he's not sure either. > > We'll check. > > - (Re. 5) What headers are missing according to you? The current ASN.1 > > starts with "MEDIA-GATEWAY-CONTROL DEFINITIONS AUTOMATIC TAGS::=". I > > checked the syntax with the OSS tools and didn't find a problem. > > - (Re. 6) I believe this was brought in through MSF and I never > > checked. Having looked up Q.2941.1 now, I agree that 4 octets is > > restrictive. > > > > John > > > > "Drage, Keith" wrote: > > > > > > Attached please find a number of editorial comments on the Geneva output > > > document, which we also understand is identical to the MEGACO last call > > > document. These points are not intended to be controversial. In the event > > > that discussion is required to resolve such a comment, then we will withdraw > > > the comment in order to allow the document to proceed. > > > > > > 1) Abbreviations. "BRI" is never used and therefore should be removed > > > from the list of abbreviations. > > > > > > 2) References. Q.724 is never used and should be removed. > > > > > > 3) References and annex C. Where a reference is only used in annex C, > > > we believe in general in most cases these should be undated (i.e. the latest > > > version of the referenced document applies). This in particular applies to > > > Q.931, Q. 2931, Q.763 where ITU-T SG11 have no intention of changing > > > codepoints to different values, but do reserve the right to add new values. > > > Surely the whole ethos of annex C is that new values do get automatically > > > incorporated. > > > > > > 4) References (and annex C if comment 3 not accepted). Some of the > > > dates are incorrect. Q.761-4 have a date of December 1999 as that was > > > decided last year. Q.2931 should reflect the date of the latest amendment > > > (4) which we believe is also December 1999. > > > > > > 5) Annex A. We could not find the module header, or an exports > > > statement, for the ASN.1. The module header is mandatory parts of the ASN.1, > > > and gives that module an object identifier, which is needed for inport to > > > anything else. > > > > > > 6) Annex C, C.8, generic identifier transport. We are not sure how you > > > fit this into four octets. Is there some subset of the generic identifier > > > transport information element that is being used? Various codings of this > > > information element get very, very long. > > > > > > 7) Annex C, C.9, ITC has a reference to a note 2, which is not in the > > > table. Is this a spurious inport from the referenced standard? If so, we > > > believe it can be deleted. > > > > > > 8) Annex C, C.9. References to Q.931 need to identify that the > > > references are to the encoding in the Bearer capability information element, > > > and not to the Low layer information element. The latter has identical > > > fields with the same code values, but has a more extensive range of values > > > assigned. This is because some values (particularly at layer 3) are only > > > defined for end user to addressed end user usage. I believe in H.248 only > > > the more restricted list in the Bearer capability information element would > > > be valid. > > > > > > Keith Drage > > > > > > > --------------------------------------------------------------- > > > > Keith Drage (keith.drage@siemenscomms.co.uk) > > > > Siemens Communications Limited, > > > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > > > --------------------------------------------------------------- > > > > Internet communications are not secure and therefore Siemens > > > > Communications Limited does not accept legal responsibility for the > > > > contents of this message. Any views or opinions presented are solely those > > > > of the author and do not necessarily represent those of Siemens > > > > Communications Limited unless otherwise specifically stated. > > > > > > > > > > > > -- > > John Segers email: jsegers@lucent.com > > Lucent Technologies Room HE 306 > > Dept. Forward Looking Work phone: +31 35 687 4724 > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 15 10:14:08 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02566 for ; Wed, 15 Mar 2000 10:14:07 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.75296A00@standards.nortelnetworks.com>; Wed, 15 Mar 2000 10:08:49 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 89266 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 15 Mar 2000 10:07:05 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D18B8A00@standards.nortelnetworks.com>; Wed, 15 Mar 2000 9:57:05 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id KAA12261; Wed, 15 Mar 2000 10:01:06 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id KAA11411; Wed, 15 Mar 2000 10:01:03 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Mar 2000 09:56:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF208AD7@whq-msgusr-02.fore.com> Date: Wed, 15 Mar 2000 10:00:31 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Descriptor processing order X-To: Steven Magnell To: MEGACO@STANDARDS.NORTELNETWORKS.COM Thanks for pointing this out. I believe we should change the ASN.1 to allow descriptors in any order, and specify that they are processed in the order received. This allows the MGC to control what happens, in what order. If we were to go in the other direction; forcing a particular order, then we get into a debate about the proper order, for which I suspect there is no one right answer. Brian > -----Original Message----- > From: Steven Magnell [mailto:magnells@dialogic.com] > Sent: Wednesday, March 15, 2000 4:55 AM > To: MEGACO@standards.nortelnetworks.com > Subject: Re: Descriptor processing order > > > This discussion exposes a syntactic difference between the > binary and text > encodings of the protocol. The binary encoding describes the list of > descriptors in the Add/Move/Modify commands as a SEQUENCE > which follows the > order given by the abstract API descriptions of the commands. The text > encoding, on the other hand, specifies only a list of > parameters where the > parameters are the separately defined as the descriptors, allowing > variations in the order of descriptors. > > Chip's expectation that the order of descriptors can be > reversed in order > to affect the order of processing is only possible using the > text encoding. > > Given this difference either the binary encoding syntax > should be changed > or the order of descriptor interpretation should follow the > order given in > the abstract API. > > steve > > At 07:48 AM 3/15/00 +0100, Christian Groves wrote: > >G'Day Chip and Brian, > > > >Sounds like a good idea it what I've always assumed (but as > we've found > >out several times with this protocol, assumptions are dangerous). Is > >this something for the implementor's guide or an error fix? > > > >Cheers, Christian > > > >Chip Sharp wrote: > >> > >> I think this would resolve ambiguities and possible > anomalous results on > >> descriptor processing. If the MGC wants the MG to process > the descriptors > >> in a particular order, it would then have control. > >> > >> In the particular example I cited, I would assume that the > MGC would always > >> place TerminationStateDescriptor before EventsDescriptor > (thus having > >> EventBufferControl processed before the new > EventsDescriptor); however, it > >> would have the ability to reverse the order if it needed to. > >> > >> Chip > >> > >> At 09:22 AM 3/14/00 -0500, Rosen, Brian wrote: > >> >Good point. I think we should add text that says > >> >descriptors are processed in the order they appear > >> >in the command, just like commands are processed > >> >in the order they appear in the action. > >> > > >> >Brian > >> > > >> > > -----Original Message----- > >> > > From: Chip Sharp [mailto:chsharp@cisco.com] > >> > > Sent: Monday, March 13, 2000 8:33 PM > >> > > To: MEGACO@standards.nortelnetworks.com > >> > > Subject: Descriptor processing order > >> > > > >> > > > >> > > Due to a previous question on event handling, I went through > >> > > the output of > >> > > SG16 (TD37) looking for text on the ordering of processing of > >> > > descriptors. > >> > > > >> > > However, I could find no text in the document that describes > >> > > in what order > >> > > a MG or MGC should process descriptors. I was specifically > >> > > wondering if > >> > > the TerminationStateDescriptor was processed before the > >> > > EventsDescriptor. This has implications in that the order of > >> > > processing > >> > > the value of the EventBufferControl parameter in the > >> > > TerminationStateDescriptor and the EventsDescriptor will > >> > > affect how events > >> > > in the EventBuffer are processed. > >> > > > >> > > If TerminationStateDescriptor is processed first and > >> > > EventBufferControl=Off > >> > > (previous LockStep), then all events are discarded. If > >> > > EventsDescriptor is > >> > > processed first then at least one more event will be reported > >> > > before the > >> > > EventBuffer is flushed (ignoring the previous discussion as > >> > > to whether this > >> > > is desirable or not). > >> > > > >> > > It seems there may be any number of conditions like this that > >> > > will depend > >> > > on ordering of processing of descriptors in the command. > >> > > > >> > > Shouldn't there be some basic text in the spec that either > >> > > specifies that > >> > > the receiver of a command should process the > descriptors in the order > >> > > received or that the receiver can process them in any order > >> > > desired? I > >> > > prefer the former. The latter seems a little indeterminate. > >> > > > >> > > If there is already text of this nature in the document, > >> > > please educate me > >> > > as to its location. > >> > > > >> > > Thanks, > >> > > Chip > >> > > Support NetAid! http://www.netaid.org > >> > > -------------------------------------------------- > >> > > Chip Sharp Consulting Engineering > >> > > Cisco Systems Telco Bio-region > >> > > Reality - Love it or Leave it. > >> > > -------------------------------------------------- > >> > > > >> > >> Support NetAid! http://www.netaid.org > >> -------------------------------------------------- > >> Chip Sharp Consulting Engineering > >> Cisco Systems Telco Bio-region > >> Reality - Love it or Leave it. > >> -------------------------------------------------- > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 15 10:20:34 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05184 for ; Wed, 15 Mar 2000 10:20:34 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.72D376A0@standards.nortelnetworks.com>; Wed, 15 Mar 2000 10:15:54 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 89267 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 15 Mar 2000 10:15:05 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EF609AB0@standards.nortelnetworks.com>; Wed, 15 Mar 2000 10:05:04 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id KAA13257; Wed, 15 Mar 2000 10:09:14 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id KAA13426; Wed, 15 Mar 2000 10:09:17 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Wed, 15 Mar 2000 10:04:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF208AD8@whq-msgusr-02.fore.com> Date: Wed, 15 Mar 2000 10:08:45 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: sub-list value type for package stats X-To: Vikas Salota To: MEGACO@STANDARDS.NORTELNETWORKS.COM Can anyone come up with a statistic that has anything other than a single value? If there is, then we should make statistics use parmValue. I'm not sure I understand the problem of parmValue not allowing a sublist. It seems to: parmValue = (EQUAL alternativeValue/ INEQUAL VALUE) alternativeValue = ( VALUE / LSBRKT VALUE *(COMMA VALUE) RSBRKT / LSBRKT VALUE DOT DOT VALUE RSBRKT ) Brian > -----Original Message----- > From: Vikas Salota [mailto:vsalota@ficon-tech.com] > Sent: Wednesday, March 15, 2000 4:57 AM > To: MEGACO@standards.nortelnetworks.com > Subject: sub-list value type for package stats > > > Hi ! > There seems to be a discrepancy in the possible package stats values > type as defined in Sec 12.2 and the ABNF. Sec 12.2 suggests > that package > stats can be of type sub-list but the ABNF does not support sub-list > values for stats values. To support the sub-list type stats > values, the > ABNF definition > statisticsParameter = pkgdName EQUAL VALUE > should be changed to > statisticsParameter = pkgdName EQUAL (VALUE / LSBRKT > VALUE *(COMMA VALUE) RSBRKT ) > > Although similar change would have been necessitated in the definition > of parmValue too if it were not for the support of > over-specification of > these values. Since due to possible over specification of > these values, > sub-list type of values for package signals and events can be > supported > with the current definition of parmValue. But then we can't > over specify > package events/signals of type sub-list because a list of values for > these type of events/signals would always be interpreted as > the sub-list > value. If we have to support over specification of sub-list typed > events/signals, the definition of parmValue should be changed > to support > list of sub-list values too. > > with regards > Vikas Salota > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 15 10:24:46 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06789 for ; Wed, 15 Mar 2000 10:24:44 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.036C5EC0@standards.nortelnetworks.com>; Wed, 15 Mar 2000 10:19:57 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 89278 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 15 Mar 2000 10:18:22 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.651D7160@standards.nortelnetworks.com>; Wed, 15 Mar 2000 10:08:22 -0500 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id HAA19275; Wed, 15 Mar 2000 07:12:21 -0800 (PST) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <38C79859.CB9D775E@ficon-tech.com> <38C8F28D.BC9CA1DD@lucent.com> <38C91CEF.8C7BEB8A@cisco.com> <38CF954F.35898922@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38CFD31C.CE57405F@cisco.com> Date: Wed, 15 Mar 2000 10:14:53 -0800 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Subject: Re: [Fwd: Issues in V16 Draft] X-To: John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit John Segers wrote: > Flemming Andreasen wrote: > [snip] > > > > 1. Section 11.2 on Cold Start says that : > > > > "Upon failure to obtain a reply, either from the Primary MGC, or a > > > > designated successor, the MG tries its pre-provisioned Secondary MGCs, > > > > in order. If the MG is unable to comply and it has established a > > > > transport connection to the MGC, it should close that connection. In any > > > > event, it should reject all subsequent requests from the MGC with Error > > > > 406 Version Not Supported." > > > > The situation of MG not being able to comply and sending errors of > > > > Version not supported, seems to be appropriate only for the case of > > > > Version negotiation failure and not as a general case. If MG is unable > > > > to comply due to some other reason, then the appropriate error should be > > > > returned. > > > > > > I checked back in my notes from the ITU meeting and before, and found > > > out that the offending text has been introduced in January (on the > > > 24th). I don't remember who suggested the change at that time. All I > > > remember is that there was a request to put in text about the error > > > message to be returned. Even for that purpose, the text looks strange > > > (what does "comply" refer to?). Suggestions? > > > > I made the same comment and I think you are looking at Section 11.3, not 11.2. The > > change got introduced in v16, and when you look at a similar change made in Section > > 11.3 it seems like a simple editorial mistake. If it's not, discussion is clearly > > needed. > > I agree that it is better to remove the text than to leave it in. > > > > > 2. In Section 7.2.5, it is clarified that if DigitMap is requested in an > > > > AuditValue command with TerminationID ALL, then all the digit maps > > > > defined in the gateway are returned. Since only the digit map names are > > > > getting returned here, it would not be possible to return those digit > > > > maps specified by MGC as part of the Event Descriptor, since they do not > > > > have names associated with them. > > > > > > For the case that one termination is addressed, the text reads > > > "DigitMapDescriptor returns the name or value of the current DigitMap > > > for the Termination.", which I interpreted as: if the DM has a name, the > > > name is returned, otherwise the value. I have to admit that the text is > > > not very clear, but your assumption that only names can be returned does > > > not seem right. > > > > > > > There is however another issue of shadowing between the root termination and other > > terminations. > > I think that the digit maps defined on the root termination should only > be returned as being defined on root. There does not seem to be a need > to return the same digit map for all individual terminations too. Yes - please ignore my shadowing comment. -- Flemming > > > John > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 306 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 15 11:06:06 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23870 for ; Wed, 15 Mar 2000 11:06:05 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C105B760@standards.nortelnetworks.com>; Wed, 15 Mar 2000 11:01:03 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 89431 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 15 Mar 2000 10:59:35 -0500 Received: from auemlsrv.firewall.lucent.com (192.11.223.161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8C6E46C0@standards.nortelnetworks.com>; Wed, 15 Mar 2000 10:59:34 -0500 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 LAA29349 for ; Wed, 15 Mar 2000 11:03:47 -0500 (EST) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA29332 for ; Wed, 15 Mar 2000 11:03:46 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA13746; Wed, 15 Mar 2000 17:03:45 +0100 (MET) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA13737; Wed, 15 Mar 2000 17:03:43 +0100 (MET) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <38CF322F.C9BB3964@ericsson.com> <4.2.2.20000314095121.00b1ade0@dogwood.cisco.com> <4.2.2.20000315081224.00aa75e0@dogwood.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38CFB456.8D2D5E53@lucent.com> Date: Wed, 15 Mar 2000 17:03:34 +0100 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: Descriptor processing order To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Chip, It seems that if you want the flexibility that you proposed in an earlier message in this thread, the issues get linked: - processing in order of receipt - variation in ordering of descriptors allowed, to allow, e.g., eventBufferControl to be set before or after processing new eventsdescriptor. I'm not sure that we need this flexibility, but I can imagine that it will be hard to agree on a fixed order of processing. I'm not going to propose an order, but show how I think the ASN.1 would have to be changed to allow variation in order of descriptors. Instead of AmmRequest ::= SEQUENCE { terminationID TerminationIDList, mediaDescriptor MediaDescriptor OPTIONAL, ModemDescriptor ModemDescriptor OPTIONAL, muxDescriptor MuxDescriptor OPTIONAL, eventsDescriptor EventsDescriptor OPTIONAL, eventBufferDescriptor EventBufferDescriptor OPTIONAL, signalsDescriptor SignalsDescriptor OPTIONAL, digitMapDescriptor DigitMapDescriptor OPTIONAL, auditDescriptor AuditDescriptor OPTIONAL, ... } we would get AmmRequest ::= SEQUENCE { terminationID TerminationIDList, descriptors SEQUENCE OF AmmDescriptor, -- At most one descriptor of each type (see AmmDescriptor) -- allowed in the sequence ... } AmmDescriptor ::= CHOICE { mediaDescriptor MediaDescriptor, modemDescriptor ModemDescriptor, muxDescriptor MuxDescriptor, eventsDescriptor EventsDescriptor, eventBufferDescriptor EventBufferDescriptor, signalsDescriptor SignalsDescriptor, digitMapDescriptor DigitMapDescriptor, auditDescriptor AuditDescriptor, ... } It's quite a change if you count the number of lines changed, but it can still be regarded as an erratum that fixes a discrepancy between ABNF and ASN.1. John Chip Sharp wrote: > > I hadn't thought of it before, but these are two separate issues. > > The first issue as noted by Steve is that the text encoding doesn't specify > an order on the descriptors in the command. This seems to apply only to > the text encoding since the binary encoding does restrict order. > > The second issue is the order of processing, regardless of order of > descriptors in the command. This issue applies to both text and binary > encoding. > > There seems to be an agreement on some basic text to clarify the second > issue (process descriptors in order of receipt). In fact I would classify > this as "errata". > > The first issue is much thornier. I don't really have an opinion one way > or other. > > Chip > > P.S. Enjoy Adelaide. I won't make it this time. > > At 04:54 AM 3/15/00 -0500, Steven Magnell wrote: > >This discussion exposes a syntactic difference between the binary and text > >encodings of the protocol. The binary encoding describes the list of > >descriptors in the Add/Move/Modify commands as a SEQUENCE which follows the > >order given by the abstract API descriptions of the commands. The text > >encoding, on the other hand, specifies only a list of parameters where the > >parameters are the separately defined as the descriptors, allowing > >variations in the order of descriptors. > > > >Chip's expectation that the order of descriptors can be reversed in order > >to affect the order of processing is only possible using the text encoding. > > > >Given this difference either the binary encoding syntax should be changed > >or the order of descriptor interpretation should follow the order given in > >the abstract API. > > > >steve > > > >At 07:48 AM 3/15/00 +0100, Christian Groves wrote: > > >G'Day Chip and Brian, > > > > > >Sounds like a good idea it what I've always assumed (but as we've found > > >out several times with this protocol, assumptions are dangerous). Is > > >this something for the implementor's guide or an error fix? > > > > > >Cheers, Christian > > > > > >Chip Sharp wrote: > > >> > > >> I think this would resolve ambiguities and possible anomalous results on > > >> descriptor processing. If the MGC wants the MG to process the descriptors > > >> in a particular order, it would then have control. > > >> > > >> In the particular example I cited, I would assume that the MGC would > > always > > >> place TerminationStateDescriptor before EventsDescriptor (thus having > > >> EventBufferControl processed before the new EventsDescriptor); however, it > > >> would have the ability to reverse the order if it needed to. > > >> > > >> Chip > > >> > > >> At 09:22 AM 3/14/00 -0500, Rosen, Brian wrote: > > >> >Good point. I think we should add text that says > > >> >descriptors are processed in the order they appear > > >> >in the command, just like commands are processed > > >> >in the order they appear in the action. > > >> > > > >> >Brian > > >> > > > >> > > -----Original Message----- > > >> > > From: Chip Sharp [mailto:chsharp@cisco.com] > > >> > > Sent: Monday, March 13, 2000 8:33 PM > > >> > > To: MEGACO@standards.nortelnetworks.com > > >> > > Subject: Descriptor processing order > > >> > > > > >> > > > > >> > > Due to a previous question on event handling, I went through > > >> > > the output of > > >> > > SG16 (TD37) looking for text on the ordering of processing of > > >> > > descriptors. > > >> > > > > >> > > However, I could find no text in the document that describes > > >> > > in what order > > >> > > a MG or MGC should process descriptors. I was specifically > > >> > > wondering if > > >> > > the TerminationStateDescriptor was processed before the > > >> > > EventsDescriptor. This has implications in that the order of > > >> > > processing > > >> > > the value of the EventBufferControl parameter in the > > >> > > TerminationStateDescriptor and the EventsDescriptor will > > >> > > affect how events > > >> > > in the EventBuffer are processed. > > >> > > > > >> > > If TerminationStateDescriptor is processed first and > > >> > > EventBufferControl=Off > > >> > > (previous LockStep), then all events are discarded. If > > >> > > EventsDescriptor is > > >> > > processed first then at least one more event will be reported > > >> > > before the > > >> > > EventBuffer is flushed (ignoring the previous discussion as > > >> > > to whether this > > >> > > is desirable or not). > > >> > > > > >> > > It seems there may be any number of conditions like this that > > >> > > will depend > > >> > > on ordering of processing of descriptors in the command. > > >> > > > > >> > > Shouldn't there be some basic text in the spec that either > > >> > > specifies that > > >> > > the receiver of a command should process the descriptors in the order > > >> > > received or that the receiver can process them in any order > > >> > > desired? I > > >> > > prefer the former. The latter seems a little indeterminate. > > >> > > > > >> > > If there is already text of this nature in the document, > > >> > > please educate me > > >> > > as to its location. > > >> > > > > >> > > Thanks, > > >> > > Chip > > >> > > Support NetAid! http://www.netaid.org > > >> > > -------------------------------------------------- > > >> > > Chip Sharp Consulting Engineering > > >> > > Cisco Systems Telco Bio-region > > >> > > Reality - Love it or Leave it. > > >> > > -------------------------------------------------- > > >> > > > > >> > > >> Support NetAid! http://www.netaid.org > > >> -------------------------------------------------- > > >> Chip Sharp Consulting Engineering > > >> Cisco Systems Telco Bio-region > > >> Reality - Love it or Leave it. > > >> -------------------------------------------------- > > > > > Support NetAid! http://www.netaid.org > -------------------------------------------------- > Chip Sharp Consulting Engineering > Cisco Systems Telco Bio-region > Reality - Love it or Leave it. > -------------------------------------------------- -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 15 11:34:56 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05820 for ; Wed, 15 Mar 2000 11:34:55 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D244DC00@standards.nortelnetworks.com>; Wed, 15 Mar 2000 11:30:10 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 89503 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 15 Mar 2000 11:28:15 -0500 Received: from dnsmx1pya.telcordia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.280A2CA0@standards.nortelnetworks.com>; Wed, 15 Mar 2000 11:18:14 -0500 Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with SMTP id LAA02896; Wed, 15 Mar 2000 11:22:19 -0500 (EST) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852568A3.0059ECBD ; Wed, 15 Mar 2000 11:22:13 -0500 X-Lotus-FromDomain: TELCORDIA Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <852568A3.0059EBB6.00@notes949.cc.telcordia.com> Date: Wed, 15 Mar 2000 11:22:01 -0500 Reply-To: "Petros N. Mouchtaris" Sender: "Media Gateway Control (megaco)" From: "Petros N. Mouchtaris" Subject: Re: FYI: new ID draft-bouwen-megaco-isdn-00.txt X-To: Matt Holdrege To: MEGACO@STANDARDS.NORTELNETWORKS.COM Matt, Let me make sure I understand what you are saying: draft-bouwen-megaco-isdn-00.txt identifies three ISDN backhaul mechanisms: 1) Translate Q.931 messages into Megaco/H.248 events and signals 2) Embed Q.931 messages in MEGACO/H.248 as MIME attachements 3) Use IUA over SCTP You are proposing to extend option 3 to include TCP instead of SCTP and eliminate options 1 and 2. I tend to agree that option 3 is probably the most viable choice. Petros Matt Holdrege on 03/15/2000 09:01:47 AM Please respond to Matt Holdrege To: MEGACO@standards.nortelnetworks.com cc: (bcc: Petros N. Mouchtaris/Telcordia) Subject: Re: FYI: new ID draft-bouwen-megaco-isdn-00.txt I spoke to Jan today and I ought to fill in everyone else. First of all, at the last design team conference call I was able to finally express verbally my reasons for putting a TCP option into the UA's. We agreed to put a small note about TCP in the introduction with a pointer to a TCP section later in the documents. The bottom line is that SCTP is the main transport for the UA's, but TCP is a viable option in *certain* scenarios. You'll all be able to review this text in the rev's following Adelaide. So with the ability to do TCP and the seemingly best choice of the SIGTRAN IUA to transport many of us are recommending against ISDN backhaul with MEGACO. It's obviously better to have one choice in this case. At 09:42 AM 3/14/00 +0100, Bart Van Doorselaer wrote: >"Issues for Megaco - Sigtran Interworking in ISDN Access Gateways ", Jan >Bouwen, Bart Van Doorselaer, Miek Dekeyser, 03/13/2000. (71198 bytes) > >http://www.ietf.org/internet-drafts/draft-bouwen-megaco-isdn-00.txt > >This document introduces the concept of an ISDN access gateway in the >context of Megaco/H.248 and Sigtran protocols. For these ISDN access >gateways, the ISDN B channels may be controlled by the Media Gateway >Controller using megaco/H.248 while the User-to-Network signaling >running over the D channels may be relayed to the Media Gateway >Controller using either megaco/H.248 or the Sigtran protocols. The main >issues involved are: >* Megaco/H.248 and Sigtran protocols may interwork in different ways in >ISDN access gateways, leaving room for non - interoperable solutions; >* Megaco needs additional packages in order to support ISDN terminations >in the ISDN access gateway; >* A data service may be offered to ISDN users via the ISDN D- channel, >introducing the need to introduce a NAS package for the D-channel. >This document addresses these issues, proposes and explains different >solutions and suggests best practice guideline for megaco / sigtran >interworking in ISDN access gateways. > > >Enjoy the reading. > > >-- > ____________________ >Bart Van Doorselaer \ / >_______________________________________________\ /____ > \ / >Research Engineer \ ALCATEL / >DN2 Network Strategy Group >Tel : +32 3 240 86 41 Francis Wellesplein 1 >Fax : +32 3 240 99 32 B-2018 Antwerpen Belgium >_____________________________________________________\ /__________ >mailto:Bart.Van_Doorselaer@alcatel.be \ / > \/ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 15 11:47:07 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10927 for ; Wed, 15 Mar 2000 11:47:04 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8331B780@standards.nortelnetworks.com>; Wed, 15 Mar 2000 11:42:16 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 89596 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 15 Mar 2000 11:41:08 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5AD70F10@standards.nortelnetworks.com>; Wed, 15 Mar 2000 11:41:08 -0500 Received: from chsharp-tecra (chsharp-isdn.cisco.com [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id IAA19600; Wed, 15 Mar 2000 08:45:13 -0800 (PST) X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 References: <38CF322F.C9BB3964@ericsson.com> <4.2.2.20000314095121.00b1ade0@dogwood.cisco.com> <4.2.2.20000315081224.00aa75e0@dogwood.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.2.2.20000315114227.00bbb4e0@dogwood.cisco.com> Date: Wed, 15 Mar 2000 11:44:22 -0800 Reply-To: Chip Sharp Sender: "Media Gateway Control (megaco)" From: Chip Sharp Subject: Re: Descriptor processing order X-To: John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <38CFB456.8D2D5E53@lucent.com> Sorry if I misled you. I really don't care about the flexibility. Others might. :-) Chip At 05:03 PM 3/15/00 +0100, John Segers wrote: >Chip, > >It seems that if you want the flexibility that you proposed in an >earlier message in this thread, the issues get linked: > >- processing in order of receipt >- variation in ordering of descriptors allowed, to allow, e.g., >eventBufferControl to be set before or after processing new >eventsdescriptor. > >I'm not sure that we need this flexibility, but I can imagine that it >will be hard to agree on a fixed order of processing. I'm not going to >propose an order, but show how I think the ASN.1 would have to be >changed to allow variation in order of descriptors. Instead of > >AmmRequest ::= SEQUENCE >{ > terminationID TerminationIDList, > mediaDescriptor MediaDescriptor OPTIONAL, > ModemDescriptor ModemDescriptor OPTIONAL, > muxDescriptor MuxDescriptor OPTIONAL, > eventsDescriptor EventsDescriptor OPTIONAL, > eventBufferDescriptor EventBufferDescriptor OPTIONAL, > signalsDescriptor SignalsDescriptor OPTIONAL, > digitMapDescriptor DigitMapDescriptor OPTIONAL, > auditDescriptor AuditDescriptor OPTIONAL, > ... >} > >we would get > >AmmRequest ::= SEQUENCE >{ > terminationID TerminationIDList, > descriptors SEQUENCE OF AmmDescriptor, > -- At most one descriptor of each type (see AmmDescriptor) > -- allowed in the sequence > ... >} > >AmmDescriptor ::= CHOICE >{ > mediaDescriptor MediaDescriptor, > modemDescriptor ModemDescriptor, > muxDescriptor MuxDescriptor, > eventsDescriptor EventsDescriptor, > eventBufferDescriptor EventBufferDescriptor, > signalsDescriptor SignalsDescriptor, > digitMapDescriptor DigitMapDescriptor, > auditDescriptor AuditDescriptor, > ... >} > >It's quite a change if you count the number of lines changed, but it can >still be regarded as an erratum that fixes a discrepancy between ABNF >and ASN.1. Ooo. Correct usage of the singular form of errata. Nice. :-) >John > >Chip Sharp wrote: > > > > I hadn't thought of it before, but these are two separate issues. > > > > The first issue as noted by Steve is that the text encoding doesn't specify > > an order on the descriptors in the command. This seems to apply only to > > the text encoding since the binary encoding does restrict order. > > > > The second issue is the order of processing, regardless of order of > > descriptors in the command. This issue applies to both text and binary > > encoding. > > > > There seems to be an agreement on some basic text to clarify the second > > issue (process descriptors in order of receipt). In fact I would classify > > this as "errata". > > > > The first issue is much thornier. I don't really have an opinion one way > > or other. > > > > Chip > > > > P.S. Enjoy Adelaide. I won't make it this time. > > > > At 04:54 AM 3/15/00 -0500, Steven Magnell wrote: > > >This discussion exposes a syntactic difference between the binary and text > > >encodings of the protocol. The binary encoding describes the list of > > >descriptors in the Add/Move/Modify commands as a SEQUENCE which > follows the > > >order given by the abstract API descriptions of the commands. The text > > >encoding, on the other hand, specifies only a list of parameters where the > > >parameters are the separately defined as the descriptors, allowing > > >variations in the order of descriptors. > > > > > >Chip's expectation that the order of descriptors can be reversed in order > > >to affect the order of processing is only possible using the text > encoding. > > > > > >Given this difference either the binary encoding syntax should be changed > > >or the order of descriptor interpretation should follow the order given in > > >the abstract API. > > > > > >steve > > > > > >At 07:48 AM 3/15/00 +0100, Christian Groves wrote: > > > >G'Day Chip and Brian, > > > > > > > >Sounds like a good idea it what I've always assumed (but as we've found > > > >out several times with this protocol, assumptions are dangerous). Is > > > >this something for the implementor's guide or an error fix? > > > > > > > >Cheers, Christian > > > > > > > >Chip Sharp wrote: > > > >> > > > >> I think this would resolve ambiguities and possible anomalous > results on > > > >> descriptor processing. If the MGC wants the MG to process the > descriptors > > > >> in a particular order, it would then have control. > > > >> > > > >> In the particular example I cited, I would assume that the MGC would > > > always > > > >> place TerminationStateDescriptor before EventsDescriptor (thus having > > > >> EventBufferControl processed before the new EventsDescriptor); > however, it > > > >> would have the ability to reverse the order if it needed to. > > > >> > > > >> Chip > > > >> > > > >> At 09:22 AM 3/14/00 -0500, Rosen, Brian wrote: > > > >> >Good point. I think we should add text that says > > > >> >descriptors are processed in the order they appear > > > >> >in the command, just like commands are processed > > > >> >in the order they appear in the action. > > > >> > > > > >> >Brian > > > >> > > > > >> > > -----Original Message----- > > > >> > > From: Chip Sharp [mailto:chsharp@cisco.com] > > > >> > > Sent: Monday, March 13, 2000 8:33 PM > > > >> > > To: MEGACO@standards.nortelnetworks.com > > > >> > > Subject: Descriptor processing order > > > >> > > > > > >> > > > > > >> > > Due to a previous question on event handling, I went through > > > >> > > the output of > > > >> > > SG16 (TD37) looking for text on the ordering of processing of > > > >> > > descriptors. > > > >> > > > > > >> > > However, I could find no text in the document that describes > > > >> > > in what order > > > >> > > a MG or MGC should process descriptors. I was specifically > > > >> > > wondering if > > > >> > > the TerminationStateDescriptor was processed before the > > > >> > > EventsDescriptor. This has implications in that the order of > > > >> > > processing > > > >> > > the value of the EventBufferControl parameter in the > > > >> > > TerminationStateDescriptor and the EventsDescriptor will > > > >> > > affect how events > > > >> > > in the EventBuffer are processed. > > > >> > > > > > >> > > If TerminationStateDescriptor is processed first and > > > >> > > EventBufferControl=Off > > > >> > > (previous LockStep), then all events are discarded. If > > > >> > > EventsDescriptor is > > > >> > > processed first then at least one more event will be reported > > > >> > > before the > > > >> > > EventBuffer is flushed (ignoring the previous discussion as > > > >> > > to whether this > > > >> > > is desirable or not). > > > >> > > > > > >> > > It seems there may be any number of conditions like this that > > > >> > > will depend > > > >> > > on ordering of processing of descriptors in the command. > > > >> > > > > > >> > > Shouldn't there be some basic text in the spec that either > > > >> > > specifies that > > > >> > > the receiver of a command should process the descriptors in > the order > > > >> > > received or that the receiver can process them in any order > > > >> > > desired? I > > > >> > > prefer the former. The latter seems a little indeterminate. > > > >> > > > > > >> > > If there is already text of this nature in the document, > > > >> > > please educate me > > > >> > > as to its location. > > > >> > > > > > >> > > Thanks, > > > >> > > Chip > > > >> > > Support NetAid! http://www.netaid.org > > > >> > > -------------------------------------------------- > > > >> > > Chip Sharp Consulting Engineering > > > >> > > Cisco Systems Telco Bio-region > > > >> > > Reality - Love it or Leave it. > > > >> > > -------------------------------------------------- > > > >> > > > > > >> > > > >> Support NetAid! http://www.netaid.org > > > >> -------------------------------------------------- > > > >> Chip Sharp Consulting Engineering > > > >> Cisco Systems Telco Bio-region > > > >> Reality - Love it or Leave it. > > > >> -------------------------------------------------- > > > > > > > > Support NetAid! http://www.netaid.org > > -------------------------------------------------- > > Chip Sharp Consulting Engineering > > Cisco Systems Telco Bio-region > > Reality - Love it or Leave it. > > -------------------------------------------------- > >-- >John Segers email: jsegers@lucent.com >Lucent Technologies Room HE 306 >Dept. Forward Looking Work phone: +31 35 687 4724 >P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. -------------------------------------------------- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 15 12:20:09 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24842 for ; Wed, 15 Mar 2000 12:20:05 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.21E8AE20@standards.nortelnetworks.com>; Wed, 15 Mar 2000 12:15:20 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 89655 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 15 Mar 2000 12:13:55 -0500 Received: from mail-dns1-nj.dialogic.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EED5BAA0@standards.nortelnetworks.com>; Wed, 15 Mar 2000 12:13:54 -0500 Received: from mail4.dialogic.com ([146.152.6.40]) by mail-dns1-nj.dialogic.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.11 1999/11/10 17:27:15 spurcell Exp $) with ESMTP id RAA28356 for ; Wed, 15 Mar 2000 17:19:44 GMT Received: from exchange3nj.dialogic.com (mailnj.dialogic.com [146.152.3.18]) by mail4.dialogic.com (PMDF V5.2-31 #40816) with ESMTP id <0FRH0019Q422HQ@mail4.dialogic.com> for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 15 Mar 2000 12:18:02 -0500 (EST) Received: from stieglitz (test-addr.dialogic.com [146.152.2.63]) by exchange3nj.dialogic.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id G0W0NF83; Wed, 15 Mar 2000 12:17:59 -0500 X-Sender: magnells@exchange1nj.dialogic.com MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <38CFB456.8D2D5E53@lucent.com> <38CF322F.C9BB3964@ericsson.com> <4.2.2.20000314095121.00b1ade0@dogwood.cisco.com> <4.2.2.20000315081224.00aa75e0@dogwood.cisco.com> Message-ID: <3.0.3.32.20000315121748.00781a28@exchange1nj.dialogic.com> Date: Wed, 15 Mar 2000 12:17:48 -0500 Reply-To: Steven Magnell Sender: "Media Gateway Control (megaco)" From: Steven Magnell Subject: Re: Descriptor processing order To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4.2.2.20000315114227.00bbb4e0@dogwood.cisco.com> Content-Transfer-Encoding: 7BIT Like Chip, I am not as concerned with the flexibility, but more concerned with consistency and clarity. John's proposal happens to address the consistency part for this element of the protocol. It make the two encodings consistent. and defines the operational order for processing descriptors. Chip's original note addresses the operational ambiguity. Both should be adopted as errata. steve At 11:44 AM 3/15/00 -0800, Chip Sharp wrote: >Sorry if I misled you. I really don't care about the flexibility. Others >might. >:-) >Chip > >At 05:03 PM 3/15/00 +0100, John Segers wrote: >>Chip, >> >>It seems that if you want the flexibility that you proposed in an >>earlier message in this thread, the issues get linked: >> >>- processing in order of receipt >>- variation in ordering of descriptors allowed, to allow, e.g., >>eventBufferControl to be set before or after processing new >>eventsdescriptor. >> >>I'm not sure that we need this flexibility, but I can imagine that it >>will be hard to agree on a fixed order of processing. I'm not going to >>propose an order, but show how I think the ASN.1 would have to be >>changed to allow variation in order of descriptors. Instead of >> >>AmmRequest ::= SEQUENCE >>{ >> terminationID TerminationIDList, >> mediaDescriptor MediaDescriptor OPTIONAL, >> ModemDescriptor ModemDescriptor OPTIONAL, >> muxDescriptor MuxDescriptor OPTIONAL, >> eventsDescriptor EventsDescriptor OPTIONAL, >> eventBufferDescriptor EventBufferDescriptor OPTIONAL, >> signalsDescriptor SignalsDescriptor OPTIONAL, >> digitMapDescriptor DigitMapDescriptor OPTIONAL, >> auditDescriptor AuditDescriptor OPTIONAL, >> ... >>} >> >>we would get >> >>AmmRequest ::= SEQUENCE >>{ >> terminationID TerminationIDList, >> descriptors SEQUENCE OF AmmDescriptor, >> -- At most one descriptor of each type (see AmmDescriptor) >> -- allowed in the sequence >> ... >>} >> >>AmmDescriptor ::= CHOICE >>{ >> mediaDescriptor MediaDescriptor, >> modemDescriptor ModemDescriptor, >> muxDescriptor MuxDescriptor, >> eventsDescriptor EventsDescriptor, >> eventBufferDescriptor EventBufferDescriptor, >> signalsDescriptor SignalsDescriptor, >> digitMapDescriptor DigitMapDescriptor, >> auditDescriptor AuditDescriptor, >> ... >>} >> >>It's quite a change if you count the number of lines changed, but it can >>still be regarded as an erratum that fixes a discrepancy between ABNF >>and ASN.1. > > >Ooo. Correct usage of the singular form of errata. Nice. :-) > > >>John >> >>Chip Sharp wrote: >> > >> > I hadn't thought of it before, but these are two separate issues. >> > >> > The first issue as noted by Steve is that the text encoding doesn't specify >> > an order on the descriptors in the command. This seems to apply only to >> > the text encoding since the binary encoding does restrict order. >> > >> > The second issue is the order of processing, regardless of order of >> > descriptors in the command. This issue applies to both text and binary >> > encoding. >> > >> > There seems to be an agreement on some basic text to clarify the second >> > issue (process descriptors in order of receipt). In fact I would classify >> > this as "errata". >> > >> > The first issue is much thornier. I don't really have an opinion one way >> > or other. >> > >> > Chip >> > >> > P.S. Enjoy Adelaide. I won't make it this time. >> > >> > At 04:54 AM 3/15/00 -0500, Steven Magnell wrote: >> > >This discussion exposes a syntactic difference between the binary and text >> > >encodings of the protocol. The binary encoding describes the list of >> > >descriptors in the Add/Move/Modify commands as a SEQUENCE which >> follows the >> > >order given by the abstract API descriptions of the commands. The text >> > >encoding, on the other hand, specifies only a list of parameters where the >> > >parameters are the separately defined as the descriptors, allowing >> > >variations in the order of descriptors. >> > > >> > >Chip's expectation that the order of descriptors can be reversed in order >> > >to affect the order of processing is only possible using the text >> encoding. >> > > >> > >Given this difference either the binary encoding syntax should be changed >> > >or the order of descriptor interpretation should follow the order given in >> > >the abstract API. >> > > >> > >steve >> > > >> > >At 07:48 AM 3/15/00 +0100, Christian Groves wrote: >> > > >G'Day Chip and Brian, >> > > > >> > > >Sounds like a good idea it what I've always assumed (but as we've found >> > > >out several times with this protocol, assumptions are dangerous). Is >> > > >this something for the implementor's guide or an error fix? >> > > > >> > > >Cheers, Christian >> > > > >> > > >Chip Sharp wrote: >> > > >> >> > > >> I think this would resolve ambiguities and possible anomalous >> results on >> > > >> descriptor processing. If the MGC wants the MG to process the >> descriptors >> > > >> in a particular order, it would then have control. >> > > >> >> > > >> In the particular example I cited, I would assume that the MGC would >> > > always >> > > >> place TerminationStateDescriptor before EventsDescriptor (thus having >> > > >> EventBufferControl processed before the new EventsDescriptor); >> however, it >> > > >> would have the ability to reverse the order if it needed to. >> > > >> >> > > >> Chip >> > > >> >> > > >> At 09:22 AM 3/14/00 -0500, Rosen, Brian wrote: >> > > >> >Good point. I think we should add text that says >> > > >> >descriptors are processed in the order they appear >> > > >> >in the command, just like commands are processed >> > > >> >in the order they appear in the action. >> > > >> > >> > > >> >Brian >> > > >> > >> > > >> > > -----Original Message----- >> > > >> > > From: Chip Sharp [mailto:chsharp@cisco.com] >> > > >> > > Sent: Monday, March 13, 2000 8:33 PM >> > > >> > > To: MEGACO@standards.nortelnetworks.com >> > > >> > > Subject: Descriptor processing order >> > > >> > > >> > > >> > > >> > > >> > > Due to a previous question on event handling, I went through >> > > >> > > the output of >> > > >> > > SG16 (TD37) looking for text on the ordering of processing of >> > > >> > > descriptors. >> > > >> > > >> > > >> > > However, I could find no text in the document that describes >> > > >> > > in what order >> > > >> > > a MG or MGC should process descriptors. I was specifically >> > > >> > > wondering if >> > > >> > > the TerminationStateDescriptor was processed before the >> > > >> > > EventsDescriptor. This has implications in that the order of >> > > >> > > processing >> > > >> > > the value of the EventBufferControl parameter in the >> > > >> > > TerminationStateDescriptor and the EventsDescriptor will >> > > >> > > affect how events >> > > >> > > in the EventBuffer are processed. >> > > >> > > >> > > >> > > If TerminationStateDescriptor is processed first and >> > > >> > > EventBufferControl=Off >> > > >> > > (previous LockStep), then all events are discarded. If >> > > >> > > EventsDescriptor is >> > > >> > > processed first then at least one more event will be reported >> > > >> > > before the >> > > >> > > EventBuffer is flushed (ignoring the previous discussion as >> > > >> > > to whether this >> > > >> > > is desirable or not). >> > > >> > > >> > > >> > > It seems there may be any number of conditions like this that >> > > >> > > will depend >> > > >> > > on ordering of processing of descriptors in the command. >> > > >> > > >> > > >> > > Shouldn't there be some basic text in the spec that either >> > > >> > > specifies that >> > > >> > > the receiver of a command should process the descriptors in >> the order >> > > >> > > received or that the receiver can process them in any order >> > > >> > > desired? I >> > > >> > > prefer the former. The latter seems a little indeterminate. >> > > >> > > >> > > >> > > If there is already text of this nature in the document, >> > > >> > > please educate me >> > > >> > > as to its location. >> > > >> > > >> > > >> > > Thanks, >> > > >> > > Chip >> > > >> > > Support NetAid! http://www.netaid.org >> > > >> > > -------------------------------------------------- >> > > >> > > Chip Sharp Consulting Engineering >> > > >> > > Cisco Systems Telco Bio-region >> > > >> > > Reality - Love it or Leave it. >> > > >> > > -------------------------------------------------- >> > > >> > > >> > > >> >> > > >> Support NetAid! http://www.netaid.org >> > > >> -------------------------------------------------- >> > > >> Chip Sharp Consulting Engineering >> > > >> Cisco Systems Telco Bio-region >> > > >> Reality - Love it or Leave it. >> > > >> -------------------------------------------------- >> > > > >> > >> > Support NetAid! http://www.netaid.org >> > -------------------------------------------------- >> > Chip Sharp Consulting Engineering >> > Cisco Systems Telco Bio-region >> > Reality - Love it or Leave it. >> > -------------------------------------------------- >> >>-- >>John Segers email: jsegers@lucent.com >>Lucent Technologies Room HE 306 >>Dept. Forward Looking Work phone: +31 35 687 4724 >>P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > >Support NetAid! http://www.netaid.org >-------------------------------------------------- >Chip Sharp Consulting Engineering >Cisco Systems Telco Bio-region >Reality - Love it or Leave it. >-------------------------------------------------- > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 15 22:07:55 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12141 for ; Wed, 15 Mar 2000 22:07:55 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4459B150@standards.nortelnetworks.com>; Wed, 15 Mar 2000 22:03:17 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 90337 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 15 Mar 2000 22:01:47 -0500 Received: from smtprtp1.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0ED63300@standards.nortelnetworks.com>; Wed, 15 Mar 2000 22:01:47 -0500 Received: from zcard00m.ca.nortel.com (actually zcard00m) by smtprtp1.ntcom.nortel.net; Wed, 15 Mar 2000 22:05:54 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GT5946AK; Tue, 14 Mar 2000 09:28:39 -0500 Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GWMNT3BR; Tue, 14 Mar 2000 09:28:40 -0500 X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <4.2.2.20000313172117.00a66de0@dogwood.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38CE4D0F.A514434F@americasm01.nt.com> Date: Tue, 14 Mar 2000 09:30:39 -0500 Reply-To: Abdallah Rayhan Sender: "Media Gateway Control (megaco)" From: Abdallah Rayhan Organization: Nortel Networks Subject: Re: Descriptor processing order X-To: Chip Sharp To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I believe there is an agreement that commands are atomic, either succeed or fail and no partial commands. but I agree with you that there is no text, up to my knowledge, saying that descriptors are attempted in order. The closest we get to this is in Section 8, "Transactions guarantee ordered Command processing. That is, Commands within a Transaction are executed sequentially. Ordering of Transactions is NOT guaranteed - transactions may be executed in any order, or simultaneously." I propose adding the following sentence to the above paragraph, " All commands are atomic operations, either succeed or fail as a whole, and descriptors within commands are processed in sequence of their order." Abdallah Rayhan Chip Sharp wrote: > Due to a previous question on event handling, I went through the output of > SG16 (TD37) looking for text on the ordering of processing of descriptors. > > However, I could find no text in the document that describes in what order > a MG or MGC should process descriptors. I was specifically wondering if > the TerminationStateDescriptor was processed before the > EventsDescriptor. This has implications in that the order of processing > the value of the EventBufferControl parameter in the > TerminationStateDescriptor and the EventsDescriptor will affect how events > in the EventBuffer are processed. > > If TerminationStateDescriptor is processed first and EventBufferControl=Off > (previous LockStep), then all events are discarded. If EventsDescriptor is > processed first then at least one more event will be reported before the > EventBuffer is flushed (ignoring the previous discussion as to whether this > is desirable or not). > > It seems there may be any number of conditions like this that will depend > on ordering of processing of descriptors in the command. > > Shouldn't there be some basic text in the spec that either specifies that > the receiver of a command should process the descriptors in the order > received or that the receiver can process them in any order desired? I > prefer the former. The latter seems a little indeterminate. > > If there is already text of this nature in the document, please educate me > as to its location. > > Thanks, > Chip > Support NetAid! http://www.netaid.org > -------------------------------------------------- > Chip Sharp Consulting Engineering > Cisco Systems Telco Bio-region > Reality - Love it or Leave it. > -------------------------------------------------- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 15 22:11:56 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13545 for ; Wed, 15 Mar 2000 22:11:55 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8DF40220@standards.nortelnetworks.com>; Wed, 15 Mar 2000 22:05:20 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 90365 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 15 Mar 2000 22:04:58 -0500 Received: from smtprtp1.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.80695D30@standards.nortelnetworks.com>; Wed, 15 Mar 2000 22:04:57 -0500 Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprtp1.ntcom.nortel.net; Wed, 15 Mar 2000 22:06:42 -0500 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GXRMG3BK; Tue, 14 Mar 2000 09:06:08 -0500 Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GWMNTN8M; Tue, 14 Mar 2000 09:06:08 -0500 X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <38C79859.CB9D775E@ficon-tech.com> <38C8F28D.BC9CA1DD@lucent.com> <38CDF976.947CF35F@ficon-tech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38CE47C6.7652A579@americasm01.nt.com> Date: Tue, 14 Mar 2000 09:08:06 -0500 Reply-To: Abdallah Rayhan Sender: "Media Gateway Control (megaco)" From: Abdallah Rayhan Organization: Nortel Networks Subject: Re: [Fwd: Issues in V16 Draft] X-To: Shalini Philip To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit See comments below. Shalini Philip wrote: > > > 2. In Section 7.2.5, it is clarified that if DigitMap is requested in an > > > AuditValue command with TerminationID ALL, then all the digit maps > > > defined in the gateway are returned. Since only the digit map names are > > > getting returned here, it would not be possible to return those digit > > > maps specified by MGC as part of the Event Descriptor, since they do not > > > have names associated with them. > > > > For the case that one termination is addressed, the text reads > > "DigitMapDescriptor returns the name or value of the current DigitMap > > for the Termination.", which I interpreted as: if the DM has a name, the > > name is returned, otherwise the value. I have to admit that the text is > > not very clear, but your assumption that only names can be returned does > > not seem right. > > > > Looking at the ABNF, the Digit map descriptor requires Digit map name as a > mandatory field. So how will DMs specified without a name be returned in the Audit > Reply? > What is more troubling is "name or value" how do you request this or that ? The MGC may request only values as it might not care about names, or only names and no values or may be both in addition to values that have no names. If you leave it to the MG, it wont be right.T here should be away to say : 1- send me only names, ; I dont care if some values are excluded 2- send me only values, All DMs are included 3- send me whatever you got ; send me everything named or valued. Abdallah Rayhan From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 16 02:29:33 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00454 for ; Thu, 16 Mar 2000 02:29:33 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CD238140@standards.nortelnetworks.com>; Thu, 16 Mar 2000 2:24:48 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 90636 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 16 Mar 2000 02:23:07 -0500 Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2B0CB670@standards.nortelnetworks.com>; Thu, 16 Mar 2000 2:13:07 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id IAA14299; Thu, 16 Mar 2000 08:17:20 +0100 (MET) 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 IAA12047; Thu, 16 Mar 2000 08:17:11 +0100 (MET) Received: from ericsson.com (7-108.epa.ericsson.se [146.11.7.108]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id IAA08697; Thu, 16 Mar 2000 08:17:07 +0100 (MET) X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: <5AC7D3F55147D311AA1700A0C99583ED2C3693@beex03.sgcs.co.uk> <38CC9C51.46243391@lucent.com> <38CF0A67.6F0DE010@ericsson.com> <38CFA7F9.6101E5AB@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38D023C3.2D98A3C4@ericsson.com> Date: Thu, 16 Mar 2000 09:58:59 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Comments on MEGACO protocol X-To: John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day John, The property name is BIR. Perhaps the following change might work? BNCid 8000 6 OCTETS GIT (Generic Identifier Transport) BNCid (Octet 5a and above) Ref.: Recommendation Q.2941.1 (09/97) Cheers, Christian John Segers wrote: > > Christian, > > I believe it makes sense when it is used for binding reference. If we > only use octet 5 and above, and only use the GIT parameter for this > specific case, we should rethink the name of the parameter. Using GIT > with a reference to Q.2941.1 will undoubtedly lead to confusion. > > John > > Christian Groves wrote: > > > > G'Day Keith and John, > > > > Regarding 6 the intention was to use this as a binding reference > > (BNCid). Annex C should refer to octet 5 and above. For the BNCid the > > length as per the GIT would be 6 octets. Make sense? > > > > Cheers, Christian > > > > John Segers wrote: > > > > > > Keith, > > > > > > Most of the changes you request are ok. There's a couple that I don't > > > know about: > > > - (Re. 3) I thought that references to ITU Rec. have to be specific > > > (i.e., including a date). I asked Glen, and he's not sure either. > > > We'll check. > > > - (Re. 5) What headers are missing according to you? The current ASN.1 > > > starts with "MEDIA-GATEWAY-CONTROL DEFINITIONS AUTOMATIC TAGS::=". I > > > checked the syntax with the OSS tools and didn't find a problem. > > > - (Re. 6) I believe this was brought in through MSF and I never > > > checked. Having looked up Q.2941.1 now, I agree that 4 octets is > > > restrictive. > > > > > > John > > > > > > "Drage, Keith" wrote: > > > > > > > > Attached please find a number of editorial comments on the Geneva output > > > > document, which we also understand is identical to the MEGACO last call > > > > document. These points are not intended to be controversial. In the event > > > > that discussion is required to resolve such a comment, then we will withdraw > > > > the comment in order to allow the document to proceed. > > > > > > > > 1) Abbreviations. "BRI" is never used and therefore should be removed > > > > from the list of abbreviations. > > > > > > > > 2) References. Q.724 is never used and should be removed. > > > > > > > > 3) References and annex C. Where a reference is only used in annex C, > > > > we believe in general in most cases these should be undated (i.e. the latest > > > > version of the referenced document applies). This in particular applies to > > > > Q.931, Q. 2931, Q.763 where ITU-T SG11 have no intention of changing > > > > codepoints to different values, but do reserve the right to add new values. > > > > Surely the whole ethos of annex C is that new values do get automatically > > > > incorporated. > > > > > > > > 4) References (and annex C if comment 3 not accepted). Some of the > > > > dates are incorrect. Q.761-4 have a date of December 1999 as that was > > > > decided last year. Q.2931 should reflect the date of the latest amendment > > > > (4) which we believe is also December 1999. > > > > > > > > 5) Annex A. We could not find the module header, or an exports > > > > statement, for the ASN.1. The module header is mandatory parts of the ASN.1, > > > > and gives that module an object identifier, which is needed for inport to > > > > anything else. > > > > > > > > 6) Annex C, C.8, generic identifier transport. We are not sure how you > > > > fit this into four octets. Is there some subset of the generic identifier > > > > transport information element that is being used? Various codings of this > > > > information element get very, very long. > > > > > > > > 7) Annex C, C.9, ITC has a reference to a note 2, which is not in the > > > > table. Is this a spurious inport from the referenced standard? If so, we > > > > believe it can be deleted. > > > > > > > > 8) Annex C, C.9. References to Q.931 need to identify that the > > > > references are to the encoding in the Bearer capability information element, > > > > and not to the Low layer information element. The latter has identical > > > > fields with the same code values, but has a more extensive range of values > > > > assigned. This is because some values (particularly at layer 3) are only > > > > defined for end user to addressed end user usage. I believe in H.248 only > > > > the more restricted list in the Bearer capability information element would > > > > be valid. > > > > > > > > Keith Drage > > > > > > > > > --------------------------------------------------------------- > > > > > Keith Drage (keith.drage@siemenscomms.co.uk) > > > > > Siemens Communications Limited, > > > > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > > > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > > > > --------------------------------------------------------------- > > > > > Internet communications are not secure and therefore Siemens > > > > > Communications Limited does not accept legal responsibility for the > > > > > contents of this message. Any views or opinions presented are solely those > > > > > of the author and do not necessarily represent those of Siemens > > > > > Communications Limited unless otherwise specifically stated. > > > > > > > > > > > > > > > > -- > > > John Segers email: jsegers@lucent.com > > > Lucent Technologies Room HE 306 > > > Dept. Forward Looking Work phone: +31 35 687 4724 > > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 306 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 16 02:58:46 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12176 for ; Thu, 16 Mar 2000 02:58:41 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DF392FC0@standards.nortelnetworks.com>; Thu, 16 Mar 2000 2:53:56 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 90759 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 16 Mar 2000 02:51:57 -0500 Received: from drawbridge.ascend.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3235C370@standards.nortelnetworks.com>; Thu, 16 Mar 2000 2:41:57 -0500 Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id XAA14815; Wed, 15 Mar 2000 23:39:41 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 16 Mar 2000 07:46:10 UT Received: from porky (porky.ascend.com [192.207.23.83]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id XAA00441; Wed, 15 Mar 2000 23:46:09 -0800 (PST) Received: from ascend.com by ascend.com X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.2.2.20000315234412.00b62da0@porky> Date: Wed, 15 Mar 2000 23:46:10 -0800 Reply-To: Matt Holdrege Sender: "Media Gateway Control (megaco)" From: Matt Holdrege Subject: Re: FYI: new ID draft-bouwen-megaco-isdn-00.txt X-To: "Petros N. Mouchtaris" To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <852568A3.0059EBB6.00@notes949.cc.telcordia.com> Petros, you understand me correctly. Except that I do not say to use TCP instead of SCTP. Rather TCP is an option in certain scenarios. According to SIGTRAN agreements, implementations may use either TCP or SCTP. At 11:22 AM 3/15/00 -0500, Petros N. Mouchtaris wrote: >Matt, > >Let me make sure I understand what you are saying: >draft-bouwen-megaco-isdn-00.txt identifies three ISDN backhaul mechanisms: >1) Translate Q.931 messages into Megaco/H.248 events and signals >2) Embed Q.931 messages in MEGACO/H.248 as MIME attachements >3) Use IUA over SCTP > >You are proposing to extend option 3 to include TCP instead of SCTP and >eliminate options 1 and 2. >I tend to agree that option 3 is probably the most viable choice. > >Petros > > > > > >Matt Holdrege on 03/15/2000 09:01:47 AM > >Please respond to Matt Holdrege > >To: MEGACO@standards.nortelnetworks.com >cc: (bcc: Petros N. Mouchtaris/Telcordia) >Subject: Re: FYI: new ID draft-bouwen-megaco-isdn-00.txt > > > > >I spoke to Jan today and I ought to fill in everyone else. First of all, at >the last design team conference call I was able to finally express verbally >my reasons for putting a TCP option into the UA's. We agreed to put a small >note about TCP in the introduction with a pointer to a TCP section later in >the documents. The bottom line is that SCTP is the main transport for the >UA's, but TCP is a viable option in *certain* scenarios. You'll all be able >to review this text in the rev's following Adelaide. > >So with the ability to do TCP and the seemingly best choice of the SIGTRAN >IUA to transport many of us are recommending against ISDN backhaul with >MEGACO. It's obviously better to have one choice in this case. > >At 09:42 AM 3/14/00 +0100, Bart Van Doorselaer wrote: > >"Issues for Megaco - Sigtran Interworking in ISDN Access Gateways ", Jan > >Bouwen, Bart Van Doorselaer, Miek Dekeyser, 03/13/2000. (71198 bytes) > > > >http://www.ietf.org/internet-drafts/draft-bouwen-megaco-isdn-00.txt > > > >This document introduces the concept of an ISDN access gateway in the > >context of Megaco/H.248 and Sigtran protocols. For these ISDN access > >gateways, the ISDN B channels may be controlled by the Media Gateway > >Controller using megaco/H.248 while the User-to-Network signaling > >running over the D channels may be relayed to the Media Gateway > >Controller using either megaco/H.248 or the Sigtran protocols. The main > >issues involved are: > >* Megaco/H.248 and Sigtran protocols may interwork in different ways in > >ISDN access gateways, leaving room for non - interoperable solutions; > >* Megaco needs additional packages in order to support ISDN terminations > >in the ISDN access gateway; > >* A data service may be offered to ISDN users via the ISDN D- channel, > >introducing the need to introduce a NAS package for the D-channel. > >This document addresses these issues, proposes and explains different > >solutions and suggests best practice guideline for megaco / sigtran > >interworking in ISDN access gateways. > > > > > >Enjoy the reading. > > > > > >-- > > ____________________ > >Bart Van Doorselaer \ / > >_______________________________________________\ /____ > > \ / > >Research Engineer \ ALCATEL / > >DN2 Network Strategy Group > >Tel : +32 3 240 86 41 Francis Wellesplein 1 > >Fax : +32 3 240 99 32 B-2018 Antwerpen Belgium > >_____________________________________________________\ /__________ > >mailto:Bart.Van_Doorselaer@alcatel.be \ / > > \/ > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 16 03:17:55 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19787 for ; Thu, 16 Mar 2000 03:17:47 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.88C66BA0@standards.nortelnetworks.com>; Thu, 16 Mar 2000 3:13:00 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 90801 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 16 Mar 2000 03:11:01 -0500 Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.40C3D1D0@standards.nortelnetworks.com>; Thu, 16 Mar 2000 3:10:59 -0500 Received: from ficon-tech.com (skylab.india.ficon-tech.com [172.25.2.100]) by ficon-tech.com (8.9.3/8.8.7) with ESMTP id NAA81811; Thu, 16 Mar 2000 13:38:23 +0530 (IST) (envelope-from vsalota@ficon-tech.com) X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF208AD8@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38D097DF.2467E392@ficon-tech.com> Date: Thu, 16 Mar 2000 13:44:23 +0530 Reply-To: Vikas Salota Sender: "Media Gateway Control (megaco)" From: Vikas Salota Subject: Re: sub-list value type for package stats X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit "Rosen, Brian" wrote: > Can anyone come up with a statistic that has anything other than > a single value? > > If there is, then we should make statistics use parmValue. > > I'm not sure I understand the problem of parmValue not allowing > a sublist. It seems to: > parmValue = (EQUAL alternativeValue/ INEQUAL VALUE) > alternativeValue = ( VALUE / LSBRKT VALUE *(COMMA VALUE) RSBRKT / > LSBRKT VALUE DOT DOT VALUE RSBRKT ) Vikas>> I am sorry for not being clear. I was trying to indicate that parmValue can support sub-list values. So if MG receives a list of values for a sub-list typed package event/signal, the list of values would be treated as the sub-list value for that package event/signal. But then how do we over specify value for these types of package events/signals with the existing definition of parmValue. For overspecifiying value for these type of package events/signal, MGC would need to send a list of sub-list values for the MG to choose from, which is not possible with the current definition of parmValue. with regards Vikas Salota > > > Brian > > > -----Original Message----- > > From: Vikas Salota [mailto:vsalota@ficon-tech.com] > > Sent: Wednesday, March 15, 2000 4:57 AM > > To: MEGACO@standards.nortelnetworks.com > > Subject: sub-list value type for package stats > > > > > > Hi ! > > There seems to be a discrepancy in the possible package stats values > > type as defined in Sec 12.2 and the ABNF. Sec 12.2 suggests > > that package > > stats can be of type sub-list but the ABNF does not support sub-list > > values for stats values. To support the sub-list type stats > > values, the > > ABNF definition > > statisticsParameter = pkgdName EQUAL VALUE > > should be changed to > > statisticsParameter = pkgdName EQUAL (VALUE / LSBRKT > > VALUE *(COMMA VALUE) RSBRKT ) > > > > Although similar change would have been necessitated in the definition > > of parmValue too if it were not for the support of > > over-specification of > > these values. Since due to possible over specification of > > these values, > > sub-list type of values for package signals and events can be > > supported > > with the current definition of parmValue. But then we can't > > over specify > > package events/signals of type sub-list because a list of values for > > these type of events/signals would always be interpreted as > > the sub-list > > value. If we have to support over specification of sub-list typed > > events/signals, the definition of parmValue should be changed > > to support > > list of sub-list values too. > > > > with regards > > Vikas Salota > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 16 05:27:56 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00350 for ; Thu, 16 Mar 2000 05:27:51 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9C6A04C0@standards.nortelnetworks.com>; Thu, 16 Mar 2000 5:22:24 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 91010 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 16 Mar 2000 05:21:05 -0500 Received: from smtprtp1.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6D7E73D0@standards.nortelnetworks.com>; Thu, 16 Mar 2000 5:21:05 -0500 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp1.ntcom.nortel.net; Thu, 16 Mar 2000 05:25:02 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Mar 2000 05:25:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8F31.E325E828" Message-ID: Date: Thu, 16 Mar 2000 05:24:59 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: On 7.1.4 X-To: Flemming Andreasen 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_01BF8F31.E325E828 Content-Type: text/plain; charset="iso-8859-1" Responses below. > -----Original Message----- > From: Flemming Andreasen [SMTP:fandreas@CISCO.COM] > Sent: Saturday, March 11, 2000 11:47 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: On 7.1.4 > > Tom Taylor wrote: > > > > > > 7) 7.1.14, last sentence in paragraph beginning with "The letter 'x' > > is > > > used as a wildcard..." specifies that "As a consequence of the thrid > > > > > timing rule above, inter-event timing while matching the dot symbol > > uses > > > the short timer by default." is incorrect. The grammar may continue > > past > > > the dot symbol implying the dot could only possibly produce a > > partial > > > match which furthermore implies that the short timer may not be the > > > right one to use. The sentence should simply be removed. > > [[TomT]] Agreed that the grammar may continue past the dot, > > but > > until you get that far you have an ambiguous situation -- you don't > > know how > > many events will be mapped into the dot. The sentence is correct > > AFAIK. > > That's not entirely accurate, e.g. consider "x.#" Now, if what follows > the dot has a non-empty intersection with what precedes the dot > (ignoring timers), you have an ambigous situation. In that case you > could then apply the short timer, or alternatively simply leave the > timing rules undefined then (since you can always rewrite the digit map > to avoid this, well at least in most cases). [[TomT]] The term "ambiguous" is used in this section to mean that multiple patterns in the digit map match the current dial string. The pattern "x.F" (not "x.#") is a short way of specifying a whole series of patterns: "xF" | "xxF" | "xxxF" | ... This is why I say that the dot creates an ambiguous situation which calls for the use of the short timer. At any point in the dialling process short of receiving the final #, there is an indefinite number of patterns which the current dial string may match. > > > > > > > > 8) 7.1.14, next paragraph specifies that "A timer specified > > following a > > > dot specifies inter-event timing for all events matching the dot as > > well > > > as for subsequent events". It's unclear why the timer couldn't > > simply be > > > put in front of the dot and thereby be consistent with digit map > > timers > > > in general. In the absence of a compelling argument the sentence > > should > > > simply be removed. > > [[TomT]] Same problem as with the previous remark -- you > > don't know > > when you've gone past the dot until it's too late. If there is a > > timer both > > before and after the dot, a timer after the dot never gets used. It > > may be > > better just to say that, I suppose, leaving it up to the MGC to set a > > timer > > before the dot if it wants. > > You could have have "S.xL", but otherwise I agree. [[TomT]] At this point I see that my remarks were a little imprecise: if there is a timer both before and IMMEDIATELY after the dot, the timer after the dot doesn't get used to detect the event that indicates that the dot has been passed. It may apply to events subsequent to that point. > > > > > > > 9) 7.1.14, numbered list, item 4: The second sentence and the > > last > > > sentence seem to contradict each other. While absence of > > long-duration > > > may prevent a match from occurring, existence of long-duration > > should > > > not. Consequently, the second sentence is what should be modified. > > [[TomT]] I assume you mean the last sentence of the > > paragraph. You > > will reach this case only if all of the alternatives specifying a > > long-duration event at this point have been discarded. Thus duration > > becomes irrelevant, but only after it has been taken into account in > > the > > cases where it mattered. > > OK, I think I understand now, however the rule then seems to be > incorrect. Consider the digit map "Zx1 | x2" with input "Z1". The way I > read rule 4, the second sentence would lead us to discard alternative > "x2" which doesn't seem like the right thing to do, since "x2" doesn't > prevent us from having a long event, right ? [[TomT]] My reasoning in putting the rules together was that by specifying a long-duration event in a given position you were saying that duration really mattered at that point and should be used as a discriminator between candidate patterns. I think the logic of that position is still reasonable, but quite theoretical. It really comes down to whether the rule prevents you from doing the right thing in practical situations. > > > > > > > 10) 7.1.14, numbered list, item 5 specifies that "If exactly one > > > candidate remains, a completion event is generated indicating an > > > unambiguous match". This seems to imply that even a partial match > > (as > > > long as there is only one) will result in a digit map completion > > event, > > > which of course is incorrect. > > [[TomT]] Good catch. This really is an error. We should > > change > > that to "If exactly one candidate remains and it is fully matched, > > ..." > > > > > 11) 7.1.14, numbered list, item 5: It is entirely unclear why an > > > event triggering a partial match is not reported as part of the > > matched > > > string. In the absence of a compelling argument, the triggering > > event > > > should be included in the string as it otherwise may be processed > > twice, > > > which is hardly what the user had in mind. > > [[TomT]] I had it that way in the first place (with the > > triggering > > event distinguished by being placed in an "extra event" parameter) and > > > > consensus was to change it to what it is now. Have to overrule you on > > this > > one unless you get more support. > > Well, I think it would be more appropriate that those who argue against > explain why. There's got to be a reasonable explanation here, or > reviewing this stuff is a waste of everybody's time. [[TomT]] The reasoning was that when you activate a digit map it's what the digit map matches that is of interest -- anything left over needs to be handled in a separate processing step. The typical situation in our experience is that digit collection happens in multiple stages. The MGC doesn't want to receive that extra digit because it wants the digit to be processed against the next map to be activated. I'll have to think about the "double processing" question. Events have side effects, such as stopping signals, and clearly we only want those side effects to happen once. It may be that we need language to make sure this is what happens. > > I'm also not clear how you get duplicate > > processing -- the situation is logically equivalent to the triggering > > event > > (a non-matching digit) happening just after the digit completion event > > has > > been notified. > > Consider an IVR menu where input consists of two or more digits. For > sake of argument, let's say the only valid choice is "12", and I > erroneously enter "13". Upon entering "3" we get a mismatch and I > probably hear a recording telling me that "13" is an invalid choice and > I should try again. [[TomT]] More likely you'll get a recording telling you what the valid choices are. Under our current rules, of course, the MGC doesn't know about the 3 when the digit map completion event is reported. > When digit map processing resumes for renewed input, > "3" will now be processed and I get another mismatch. [[TomT]] Seems clear in this case that the MGC should ensure that the event buffer is cleared before resuming the operation. > The event was > processed twice which is the problem (a "process"/"discard" parameter in > event handling would of course be a general cure for such problems, but > alas, that was not to happen) > > > > > > > > > > 12) 7.1.14, second last paragraph states that "Regardles of whether > > a > > > digit map is activated, this form of event specification will cause > > the > > > individual events to be reported to the MGC as they are detected". > > Some > > > clarification is requested here. > > [[TomT]] This paragraph gives the interpretation of e.g. the > > "dd/*" > > event specification. Using the example digit map which immediately > > follows, > > a dialled "1" will be reported immediately and also accumulated into > > the > > digit map. Of course, if EventBufferControl is set to LockStep, the > > digit > > map will never complete because a new Event Descriptor will be loaded > > before > > completion can be reported. (There is a corner case with a dialled > > "0" and > > short timer expiry before the new Event descriptor is loaded, but > > let's not > > go into that.) > > I can, to some extent, understand that, although I think this dual > processing does little but underscore the lack of generality in the > event handling scheme (interesting case when you have EventBufferControl > off). At a bare minimum I think you should define that an event detected > can at most match or be consumed by a single "event" specified in the > EventsDescriptor. > > What I don't understand in the above sentence is, that it seems to imply > that the name by which we refer to an event impacts the reporting of > that event. With the current "dd" package, you may request digit map > matching without by only requesting the "Digit Map Completion" event, > i.e. do not request DTMF digits (correct ?). Thus I might define another > package, call it "dd2" that only consists of this particular event. What > the above sentence now implies is, that when I request "dd/ce", I will > process according to the digit map, but when I request "dd/*", which can > only expand to "dd/ce", I will report the digits invidually. Doesn't > seem right. [[TomT]] It seems like you typed this one a bit quickly. The problem is that dd/* currently includes within its scope both the individual digit events and the digit map completion event. If you moved the latter off to an extension package dd2, then I think we would have: - dd/* reports only individual digit events - dd2/* reports only the digit map completion event. > -- Flemming > > -- > Flemming Andreasen > Cisco Systems ------_=_NextPart_001_01BF8F31.E325E828 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: On 7.1.4

Responses = below.

    -----Original Message-----
    From:   Flemming Andreasen = [SMTP:fandreas@CISCO.COM]
    Sent:   Saturday, March 11, 2000 11:47 AM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = On 7.1.4

    Tom Taylor wrote:

    >
    > > 7) 7.1.14, last sentence in = paragraph beginning with "The letter 'x'
    > is
    > > used as a wildcard..." = specifies that "As a consequence of the thrid
    >
    > > timing rule above, = inter-event timing while matching the dot symbol
    > uses
    > > the short timer by = default." is incorrect. The grammar may continue
    > past
    > > the dot symbol implying the = dot could only possibly produce a
    > partial
    > > match which furthermore = implies that the short timer may not be the
    > > right one to use. The = sentence should simply be removed.
    >         = [[TomT]]  Agreed that the grammar may continue past the = dot,
    > but
    > until you get that far you have = an ambiguous situation -- you don't
    > know how
    > many events will be mapped into = the dot.  The sentence is correct
    > AFAIK.

    That's not entirely accurate, e.g. = consider "x.#" Now, if what follows
    the dot has a non-empty intersection = with what precedes the dot
    (ignoring timers), you have an = ambigous situation. In that case you
    could then apply the short timer, or = alternatively simply leave the
    timing rules undefined then (since = you can always rewrite the digit map
    to avoid this, well at least in most = cases).
    [[TomT]] 
    The term = "ambiguous" is used in this section to mean that multiple = patterns in the digit map match the current dial string.  The = pattern "x.F" (not "x.#") is a short way of = specifying a whole series of patterns: "xF" | "xxF" = | "xxxF" | ...  This is why I say that the dot creates = an ambiguous situation which calls for the use of the short = timer.  At any point in the dialling process short of receiving = the final #, there is an indefinite number of patterns which the = current dial string may match.

    >

    >
    > > 8) 7.1.14, next paragraph = specifies that "A timer specified
    > following a
    > > dot specifies inter-event = timing for all events matching the dot as
    > well
    > > as for subsequent = events". It's unclear why the timer couldn't
    > simply be
    > > put in front of the dot and = thereby be consistent with digit map
    > timers
    > > in general. In the absence = of a compelling argument the sentence
    > should
    > > simply be removed.
    >         = [[TomT]]  Same problem as with the previous remark -- you
    > don't know
    > when you've gone past the dot = until it's too late.  If there is a
    > timer both
    > before and after the dot, a = timer after the dot never gets used.  It
    > may be
    > better just to say that, I = suppose, leaving it up to the MGC to set a
    > timer
    > before the dot if it = wants.

    You could have have "S.xL", = but otherwise I agree.
    [[TomT]] 
    At this point I see = that my remarks were a little imprecise: if there is a timer both = before and IMMEDIATELY after the dot, the timer after the dot doesn't = get used to detect the event that indicates that the dot has been = passed.  It may apply to events subsequent to that = point. 

    >
    >
    > > 9) 7.1.14, numbered list, = item 4:    The second sentence and the
    > last
    > > sentence seem to contradict = each other. While absence of
    > long-duration
    > > may prevent a match from = occurring, existence of long-duration
    > should
    > > not. Consequently, the = second sentence is what should be modified.
    >         = [[TomT]]  I assume you mean the last sentence of the
    > paragraph.  You
    > will reach this case only if all = of the alternatives specifying a
    > long-duration event at this = point have been discarded.  Thus duration
    > becomes irrelevant, but only = after it has been taken into account in
    > the
    > cases where it mattered.

    OK, I think I understand now, however = the rule then seems to be
    incorrect. Consider the digit map = "Zx1 | x2" with input "Z1". The way I
    read rule 4, the second sentence = would lead us to discard alternative
    "x2" which doesn't seem = like the right thing to do, since "x2" doesn't
    prevent us from having a long event, = right ?
    [[TomT]] 
    My reasoning in = putting the rules together was that by specifying a long-duration event = in a given position you were saying that duration really mattered at = that point and should be used as a discriminator between candidate = patterns.  I think the logic of that position is still reasonable, = but quite theoretical.  It really comes down to whether the rule = prevents you from doing the right thing in practical situations. =

    >
    >
    > > 10) 7.1.14, numbered list, = item 5 specifies that "If exactly one
    > > candidate remains, a = completion event is generated indicating an
    > > unambiguous match". = This seems to imply that even a partial match
    > (as
    > > long as there is only one) = will result in a digit map completion
    > event,
    > > which of course is = incorrect.
    >         = [[TomT]]  Good catch.  This really is an error.  We = should
    > change
    > that to "If exactly one = candidate remains and it is fully matched,
    > ..."
    >
    > > 11) 7.1.14, numbered list, = item 5:    It is entirely unclear why an
    > > event triggering a partial = match is not reported as part of the
    > matched
    > > string. In the absence of a = compelling argument, the triggering
    > event
    > > should be included in the = string as it otherwise may be processed
    > twice,
    > > which is hardly what the = user had in mind.
    >         = [[TomT]]  I had it that way in the first place (with the
    > triggering
    > event distinguished by being = placed in an "extra event" parameter) and
    >
    > consensus was to change it to = what it is now.  Have to overrule you on
    > this
    > one unless you get more = support.

    Well, I think it would be more = appropriate that those who argue against
    explain why. There's got to be a = reasonable explanation here, or
    reviewing this stuff is a waste of = everybody's time.
    [[TomT]] 
    The reasoning was = that when you activate a digit map it's what the digit map matches that = is of interest -- anything left over needs to be handled in a separate = processing step.  The typical situation in our experience is that = digit collection happens in multiple stages.  The MGC doesn't want = to receive that extra digit because it wants the digit to be processed = against the next map to be activated.

    I'll have to think = about the "double processing" question.  Events have = side effects, such as stopping signals, and clearly we only want those = side effects to happen once.  It may be that we need language to = make sure this is what happens. 


    > I'm also not clear how you get = duplicate
    > processing -- the situation is = logically equivalent to the triggering
    > event
    > (a non-matching digit) happening = just after the digit completion event
    > has
    > been notified.

    Consider an IVR menu where input = consists of two or more digits. For
    sake of argument, let's say the only = valid choice is "12", and I
    erroneously enter "13". = Upon entering "3" we get a mismatch and I
    probably hear a recording telling me = that "13" is an invalid choice and
    I should try again.
    [[TomT]] 
    More likely you'll = get a recording telling you what the valid choices are.  Under our = current rules, of course, the MGC doesn't know about the 3 when the = digit map completion event is reported.

    When digit map processing resumes for = renewed input,
    "3" will now be processed = and I get another mismatch.
    [[TomT]] 
    Seems clear in this = case that the MGC should ensure that the event buffer is cleared before = resuming the operation.

    The event was
    processed twice which is the problem = (a "process"/"discard" parameter in
    event handling would of course be a = general cure for such problems, but
    alas, that was not to happen)



    >
    >
    > > 12) 7.1.14, second last = paragraph states that "Regardles of whether
    > a
    > > digit map is activated, = this form of event specification will cause
    > the
    > > individual events to be = reported to the MGC as they are detected".
    > Some
    > > clarification is requested = here.
    >         = [[TomT]]  This paragraph gives the interpretation of e.g. = the
    > "dd/*"
    > event specification.  Using = the example digit map which immediately
    > follows,
    > a dialled "1" will be = reported immediately and also accumulated into
    > the
    > digit map.  Of course, if = EventBufferControl is set to LockStep, the
    > digit
    > map will never complete because = a new Event Descriptor will be loaded
    > before
    > completion can be = reported.  (There is a corner case with a dialled
    > "0" and
    > short timer expiry before the = new Event descriptor is loaded, but
    > let's not
    > go into that.)

    I can, to some extent, understand = that, although I think this dual
    processing does little but underscore = the lack of generality in the
    event handling scheme (interesting = case when you have EventBufferControl
    off). At a bare minimum I think you = should define that an event detected
    can at most match or be consumed by a = single "event" specified in the
    EventsDescriptor.

    What I don't understand in the above = sentence is, that it seems to imply
    that the name by which we refer to an = event impacts the reporting of
    that event. With the current = "dd" package, you may request digit map
    matching without by only requesting = the "Digit Map Completion" event,
    i.e. do not request DTMF digits = (correct ?). Thus I might define another
    package, call it "dd2" that = only consists of this particular event. What
    the above sentence now implies is, = that when I request "dd/ce", I will
    process according to the digit map, = but when I request "dd/*", which can
    only expand to "dd/ce", I = will report the digits invidually. Doesn't
    seem right.
    [[TomT]]  It seems like you typed this = one a bit quickly.  The problem is that dd/* currently includes = within its scope both the individual digit events and the digit map = completion event.  If you moved the latter off to an extension = package dd2, then I think we would have:

     - dd/* reports = only individual digit events
     - dd2/* = reports only the digit map completion event.

    -- Flemming

    --
    Flemming Andreasen
    Cisco Systems

------_=_NextPart_001_01BF8F31.E325E828-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 16 05:28:00 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00390 for ; Thu, 16 Mar 2000 05:27:57 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9CDA2BB0@standards.nortelnetworks.com>; Thu, 16 Mar 2000 5:22:24 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 91015 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 16 Mar 2000 05:21:26 -0500 Received: from smtprtp.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7A1F7C10@standards.nortelnetworks.com>; Thu, 16 Mar 2000 5:21:26 -0500 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp.ntcom.nortel.net; Thu, 16 Mar 2000 05:25:25 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Mar 2000 05:25:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8F31.F0E294B6" Message-ID: Date: Thu, 16 Mar 2000 05:25:23 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Comments on draft-ietf-megaco-protocol-07 X-To: Flemming Andreasen 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_01BF8F31.F0E294B6 Content-Type: text/plain Responses couple of open items from your original note. > -----Original Message----- > From: Flemming Andreasen [SMTP:fandreas@CISCO.COM] > Sent: Friday, March 10, 2000 7:10 PM > > > 24) D.1.4, last paragraph specifies that "Upon receipt of of a final > > > response, an immediate confirmation shall be sent, and normal > repetition > > > timers shall be used thereafter", however it is not specified how the > > > entity determines whether the final response needs to be confirmed > > > immediately or not (consider the case where the pending was lost). A > > > specification for this needs to be added. > > Didn't see a response here. [[TomT]] Agreed that the behaviour of an MGC that receives a Transaction Pending may differ from that of an MGC which does not when the final response comes, but any possible tightening of the conditions for immediate acknowledgement of final responses (e.g. do it whenever the original transaction has been sent more than once) is just a bit of optimization. It potentially generates an extra message from the MGC to prevent an extra final Transaction Response from the MG. > > > > > > > > 25) D.1.5, last paragraph specifies that "When the MG establishes a > new > > > control association, it can retransmit to the new MGC. Alternatively, > a > > > MG may use a ServiceChange with ServiceChangeMethod equal to > > > disconnected to inform the new MGC that the MG lost one or more > > > transaction". In order to prevent duplicate transactions, it must be > > > required that transactions cannot be retransmitted T-MAX time after > > > their initial transmission. Consequently, a disconnected ServiceChange > > > *must* be issued in such cases. > > Didn't see a response here. [[TomT]] There is a problem with this paragraph -- "establishes a new control association" hides detail that should have been spelled out. That detail is which ServiceChangeMethod to use in the process. And as you say, that must be "Disconnected". ------_=_NextPart_001_01BF8F31.F0E294B6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Comments on draft-ietf-megaco-protocol-07

Responses couple of = open items from your original note.

    -----Original Message-----
    From:   Flemming Andreasen = [SMTP:fandreas@CISCO.COM]
    Sent:   Friday, March 10, 2000 7:10 PM
    > > 24) D.1.4, last paragraph = specifies that "Upon receipt of of a final
    > > response, an immediate = confirmation shall be sent, and normal repetition
    > > timers shall be used = thereafter", however it is not specified how the
    > > entity determines whether = the final response needs to be confirmed
    > > immediately or not = (consider the case where the pending was lost). A
    > > specification for this = needs to be added.

    Didn't see a response here.
    [[TomT]] 
    Agreed that the = behaviour of an MGC that receives a Transaction Pending may differ from = that of an MGC which does not when the final response comes, but any = possible tightening of the conditions for immediate acknowledgement of = final responses (e.g.  do it whenever the original transaction has = been sent more than once) is just a bit of optimization.  It = potentially generates an extra message from the MGC to prevent an extra = final Transaction Response from the MG.

    >
    > >
    > > 25) D.1.5, last paragraph = specifies that "When the MG establishes a new
    > > control association, it can = retransmit to the new MGC. Alternatively, a
    > > MG may use a ServiceChange = with ServiceChangeMethod equal to
    > > disconnected to inform the = new MGC that the MG lost one or more
    > > transaction". In order = to prevent duplicate transactions, it must be
    > > required that transactions = cannot be retransmitted T-MAX time after
    > > their initial transmission. = Consequently, a disconnected ServiceChange
    > > *must* be issued in such = cases.

    Didn't see a response here.
    [[TomT]] 
    There is a problem = with this paragraph -- "establishes a new control = association" hides detail that should have been spelled = out.

    That detail is which = ServiceChangeMethod to use in the process.  And as you say, that = must be "Disconnected".

------_=_NextPart_001_01BF8F31.F0E294B6-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 16 05:28:08 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00430 for ; Thu, 16 Mar 2000 05:28:01 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9D3E44B0@standards.nortelnetworks.com>; Thu, 16 Mar 2000 5:22:25 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 91020 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 16 Mar 2000 05:21:30 -0500 Received: from smtprich.nortel.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7C606B60@standards.nortelnetworks.com>; Thu, 16 Mar 2000 5:21:30 -0500 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprich.nortel.com; Thu, 16 Mar 2000 04:26:08 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 16 Mar 2000 04:25:13 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF8F31.E9BDD0A6" X-Orig: Message-ID: Date: Thu, 16 Mar 2000 04:25:12 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: On D.1 X-To: Flemming Andreasen 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_01BF8F31.E9BDD0A6 Content-Type: text/plain I think you're right. I suspect we were just a bit hasty in our wording of the section. > -----Original Message----- > From: Flemming Andreasen [SMTP:fandreas@CISCO.COM] > Sent: Friday, March 10, 2000 7:16 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: On D.1 > > Tom Taylor wrote > > > 21) D.1, first paragraph, last sentence specifies that "Responses must > > > be sent to the address and port from which the corresponding commands > > were sent except if the response to a handoff or failover, in which > case > > the procedures of 11.5 apply". While this may be reasonable for > > clustered systems, it does not seem reasonable for handoff between > > non-clustered systems. To enable reliable delivery of this message, > the > > response should still be sent to the source of the request, but > > otherwise the procedures of 11.5 applies. > [[TomT]] Sorry, what's the difference between what you propose > and > what's there now? > > > FSA: Lets say we have two MGCs, MA and MB controlling a gateway G. > The way the current text reads, when MA wants to handoff G to MB and > therefore sends a ServiceChange to G, G will have to send the response > to MB rather than MA. > > How does MA know if the ServiceChange got lost ? It can only figure that > out by having MB sending a confirmation to it which now dictates > synchronization between MA and MB. Instead, it would seem better to have > the response sent to MA. If synchronization is needed, it can still > occur by the new ServiceChange G will send to MB, however it's no longer > a requirement. > > -- Flemming > > > -- > Flemming Andreasen > Cisco Systems ------_=_NextPart_001_01BF8F31.E9BDD0A6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: On D.1

I think you're = right.  I suspect we were just a bit hasty in our wording of the = section.

    -----Original Message-----
    From:   Flemming Andreasen = [SMTP:fandreas@CISCO.COM]
    Sent:   Friday, March 10, 2000 7:16 PM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = On D.1

    Tom Taylor wrote

    > 21) D.1, first paragraph, last = sentence specifies that "Responses must

    > be sent to the address and port = from which the corresponding commands
    > were sent except if the response = to a handoff or failover, in which
    case
    > the procedures of 11.5 = apply". While this may be reasonable for
    > clustered systems, it does not = seem reasonable for handoff between
    > non-clustered systems. To enable = reliable delivery of this message,
    the
    > response should still be sent to = the source of the request, but
    > otherwise the procedures of 11.5 = applies.
            = [[TomT]]  Sorry, what's the difference between what you = propose
    and
    what's there now?


    FSA:    Lets say we = have two MGCs, MA and MB controlling a gateway G.
    The way the current text reads, when = MA wants to handoff G to MB and
    therefore sends a ServiceChange to G, = G will have to send the response
    to MB rather than MA.

    How does MA know if the ServiceChange = got lost ? It can only figure that
    out by having MB sending a = confirmation to it which now dictates
    synchronization between MA and MB. = Instead, it would seem better to have
    the response sent to MA. If = synchronization is needed, it can still
    occur by the new ServiceChange G will = send to MB, however it's no longer
    a requirement.

    -- Flemming


    --
    Flemming Andreasen
    Cisco Systems

------_=_NextPart_001_01BF8F31.E9BDD0A6-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 16 09:39:52 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA26090 for ; Thu, 16 Mar 2000 09:39:52 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E315FA50@standards.nortelnetworks.com>; Thu, 16 Mar 2000 9:34:55 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 91334 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 16 Mar 2000 09:34:53 -0500 Received: from dnsmx1pya.telcordia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E20FD4F0@standards.nortelnetworks.com>; Thu, 16 Mar 2000 9:34:53 -0500 Received: from notes950.cc.telcordia.com (notes950.cc.telcordia.com [128.96.244.1]) by dnsmx1pya.telcordia.com (8.9.3/8.9.3) with SMTP id JAA27503; Thu, 16 Mar 2000 09:38:53 -0500 (EST) Received: by notes950.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852568A4.00507567 ; Thu, 16 Mar 2000 09:38:49 -0500 X-Lotus-FromDomain: TELCORDIA Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <852568A4.005073F3.00@notes950.cc.telcordia.com> Date: Thu, 16 Mar 2000 09:41:23 -0500 Reply-To: Selvam Rengasami Sender: "Media Gateway Control (megaco)" From: Selvam Rengasami Subject: Re: Comments on MEGACO protocol X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM Christian, John, I think the issue that Keith is raising is an interesting one. Q.2941.1 defines a generic mechanism for transporting an identifier via the GIT in DSS2. As Keith points out, in general, the GIT length is not limited by Q.2941.1, therefore 4 or even 6 octets is not enough, if we want to support the generic mechanism. Now, if we want to support the BNC-ID mechanism (e.g., for use in conjunction with BICC), then Q.2941.3 defines how a BNC-ID is carried in the GIT. Q.2941.3 constrains the GIT length for BNC-ID value to exactly four octets (no more, no less). Specifically, Q.2941.3 gives the coding for Octet 5 (which identifies BICC [Q.1901] and for Octet 6 indicates that the identifier is a BNC-ID. In addition, Octet 6.1 (the length of the identifier) is required to be coded to a value of 4. Finally octets 6.2 through 6.5 provide the four octet BNC-ID value. If we want to allow for future variations in Q.2941.3 or even Q.2941.1, then we may want to consider allowing more than four octets for the BIR in C.8. I am basically interested in having the BNC-ID value (as defined by Q.2941.3) signaled between the MGC and the MG. Four octets would suffice for this purpose. I propose that we agree that the BIR for C.8 can only contain the BNC-ID value as defined in Q.2941.3 (i.e., octets 6.2 through 6.5) which requires no change to the document. By the way, Q.2941.3 (along with the other BICC related standards) is scheduled to be approved (decided) in the Special meeting of SG 11 on June 15. Cheers, -Selvam Rengasami Telcordia Technologies Tel: +1 732 758 5260 E-mail: srengasa@telcordia.com Christian Groves on 03/15/2000 06:58:59 PM Please respond to Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Selvam Rengasami/Telcordia) Subject: Re: Comments on MEGACO protocol G'Day John, The property name is BIR. Perhaps the following change might work? BNCid 8000 6 OCTETS GIT (Generic Identifier Transport) BNCid (Octet 5a and above) Ref.: Recommendation Q.2941.1 (09/97) Cheers, Christian John Segers wrote: > > Christian, > > I believe it makes sense when it is used for binding reference. If we > only use octet 5 and above, and only use the GIT parameter for this > specific case, we should rethink the name of the parameter. Using GIT > with a reference to Q.2941.1 will undoubtedly lead to confusion. > > John > > Christian Groves wrote: > > > > G'Day Keith and John, > > > > Regarding 6 the intention was to use this as a binding reference > > (BNCid). Annex C should refer to octet 5 and above. For the BNCid the > > length as per the GIT would be 6 octets. Make sense? > > > > Cheers, Christian > > > > John Segers wrote: > > > > > > Keith, > > > > > > Most of the changes you request are ok. There's a couple that I don't > > > know about: > > > - (Re. 3) I thought that references to ITU Rec. have to be specific > > > (i.e., including a date). I asked Glen, and he's not sure either. > > > We'll check. > > > - (Re. 5) What headers are missing according to you? The current ASN.1 > > > starts with "MEDIA-GATEWAY-CONTROL DEFINITIONS AUTOMATIC TAGS::=". I > > > checked the syntax with the OSS tools and didn't find a problem. > > > - (Re. 6) I believe this was brought in through MSF and I never > > > checked. Having looked up Q.2941.1 now, I agree that 4 octets is > > > restrictive. > > > > > > John > > > > > > "Drage, Keith" wrote: > > > > > > > > Attached please find a number of editorial comments on the Geneva output > > > > document, which we also understand is identical to the MEGACO last call > > > > document. These points are not intended to be controversial. In the event > > > > that discussion is required to resolve such a comment, then we will withdraw > > > > the comment in order to allow the document to proceed. > > > > > > > > 1) Abbreviations. "BRI" is never used and therefore should be removed > > > > from the list of abbreviations. > > > > > > > > 2) References. Q.724 is never used and should be removed. > > > > > > > > 3) References and annex C. Where a reference is only used in annex C, > > > > we believe in general in most cases these should be undated (i.e. the latest > > > > version of the referenced document applies). This in particular applies to > > > > Q.931, Q. 2931, Q.763 where ITU-T SG11 have no intention of changing > > > > codepoints to different values, but do reserve the right to add new values. > > > > Surely the whole ethos of annex C is that new values do get automatically > > > > incorporated. > > > > > > > > 4) References (and annex C if comment 3 not accepted). Some of the > > > > dates are incorrect. Q.761-4 have a date of December 1999 as that was > > > > decided last year. Q.2931 should reflect the date of the latest amendment > > > > (4) which we believe is also December 1999. > > > > > > > > 5) Annex A. We could not find the module header, or an exports > > > > statement, for the ASN.1. The module header is mandatory parts of the ASN.1, > > > > and gives that module an object identifier, which is needed for inport to > > > > anything else. > > > > > > > > 6) Annex C, C.8, generic identifier transport. We are not sure how you > > > > fit this into four octets. Is there some subset of the generic identifier > > > > transport information element that is being used? Various codings of this > > > > information element get very, very long. > > > > > > > > 7) Annex C, C.9, ITC has a reference to a note 2, which is not in the > > > > table. Is this a spurious inport from the referenced standard? If so, we > > > > believe it can be deleted. > > > > > > > > 8) Annex C, C.9. References to Q.931 need to identify that the > > > > references are to the encoding in the Bearer capability information element, > > > > and not to the Low layer information element. The latter has identical > > > > fields with the same code values, but has a more extensive range of values > > > > assigned. This is because some values (particularly at layer 3) are only > > > > defined for end user to addressed end user usage. I believe in H.248 only > > > > the more restricted list in the Bearer capability information element would > > > > be valid. > > > > > > > > Keith Drage > > > > > > > > > --------------------------------------------------------------- > > > > > Keith Drage (keith.drage@siemenscomms.co.uk) > > > > > Siemens Communications Limited, > > > > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > > > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > > > > --------------------------------------------------------------- > > > > > Internet communications are not secure and therefore Siemens > > > > > Communications Limited does not accept legal responsibility for the > > > > > contents of this message. Any views or opinions presented are solely those > > > > > of the author and do not necessarily represent those of Siemens > > > > > Communications Limited unless otherwise specifically stated. > > > > > > > > > > > > > > > > -- > > > John Segers email: jsegers@lucent.com > > > Lucent Technologies Room HE 306 > > > Dept. Forward Looking Work phone: +31 35 687 4724 > > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 306 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 16 09:43:47 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27701 for ; Thu, 16 Mar 2000 09:43:46 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.72D39DA0@standards.nortelnetworks.com>; Thu, 16 Mar 2000 9:38:56 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 91350 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 16 Mar 2000 09:37:09 -0500 Received: from dnsmx1rrc.telcordia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3351D570@standards.nortelnetworks.com>; Thu, 16 Mar 2000 9:37:09 -0500 Received: from notes950.cc.telcordia.com (notes950.cc.telcordia.com [128.96.244.1]) by dnsmx1rrc.telcordia.com (8.9.3/8.9.2) with SMTP id JAA10019; Thu, 16 Mar 2000 09:41:16 -0500 (EST) Received: by notes950.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852568A4.0050AEBA ; Thu, 16 Mar 2000 09:41:16 -0500 X-Lotus-FromDomain: TELCORDIA Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <852568A4.0050AE6C.00@notes950.cc.telcordia.com> Date: Thu, 16 Mar 2000 09:43:53 -0500 Reply-To: Selvam Rengasami Sender: "Media Gateway Control (megaco)" From: Selvam Rengasami Subject: Re: Comments on MEGACO protocol To: MEGACO@STANDARDS.NORTELNETWORKS.COM Folks, One correction to my previous e-mail. If we accept my proposal, then we should consider changing the reference from Q.2941.1 to Q.2941.3 in C.8 Cheers, -Selvam Selvam Rengasami on 03/16/2000 09:41:23 AM Please respond to Selvam Rengasami To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Selvam Rengasami/Telcordia) Subject: Re: Comments on MEGACO protocol Christian, John, I think the issue that Keith is raising is an interesting one. Q.2941.1 defines a generic mechanism for transporting an identifier via the GIT in DSS2. As Keith points out, in general, the GIT length is not limited by Q.2941.1, therefore 4 or even 6 octets is not enough, if we want to support the generic mechanism. Now, if we want to support the BNC-ID mechanism (e.g., for use in conjunction with BICC), then Q.2941.3 defines how a BNC-ID is carried in the GIT. Q.2941.3 constrains the GIT length for BNC-ID value to exactly four octets (no more, no less). Specifically, Q.2941.3 gives the coding for Octet 5 (which identifies BICC [Q.1901] and for Octet 6 indicates that the identifier is a BNC-ID. In addition, Octet 6.1 (the length of the identifier) is required to be coded to a value of 4. Finally octets 6.2 through 6.5 provide the four octet BNC-ID value. If we want to allow for future variations in Q.2941.3 or even Q.2941.1, then we may want to consider allowing more than four octets for the BIR in C.8. I am basically interested in having the BNC-ID value (as defined by Q.2941.3) signaled between the MGC and the MG. Four octets would suffice for this purpose. I propose that we agree that the BIR for C.8 can only contain the BNC-ID value as defined in Q.2941.3 (i.e., octets 6.2 through 6.5) which requires no change to the document. By the way, Q.2941.3 (along with the other BICC related standards) is scheduled to be approved (decided) in the Special meeting of SG 11 on June 15. Cheers, -Selvam Rengasami Telcordia Technologies Tel: +1 732 758 5260 E-mail: srengasa@telcordia.com Christian Groves on 03/15/2000 06:58:59 PM Please respond to Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Selvam Rengasami/Telcordia) Subject: Re: Comments on MEGACO protocol G'Day John, The property name is BIR. Perhaps the following change might work? BNCid 8000 6 OCTETS GIT (Generic Identifier Transport) BNCid (Octet 5a and above) Ref.: Recommendation Q.2941.1 (09/97) Cheers, Christian John Segers wrote: > > Christian, > > I believe it makes sense when it is used for binding reference. If we > only use octet 5 and above, and only use the GIT parameter for this > specific case, we should rethink the name of the parameter. Using GIT > with a reference to Q.2941.1 will undoubtedly lead to confusion. > > John > > Christian Groves wrote: > > > > G'Day Keith and John, > > > > Regarding 6 the intention was to use this as a binding reference > > (BNCid). Annex C should refer to octet 5 and above. For the BNCid the > > length as per the GIT would be 6 octets. Make sense? > > > > Cheers, Christian > > > > John Segers wrote: > > > > > > Keith, > > > > > > Most of the changes you request are ok. There's a couple that I don't > > > know about: > > > - (Re. 3) I thought that references to ITU Rec. have to be specific > > > (i.e., including a date). I asked Glen, and he's not sure either. > > > We'll check. > > > - (Re. 5) What headers are missing according to you? The current ASN.1 > > > starts with "MEDIA-GATEWAY-CONTROL DEFINITIONS AUTOMATIC TAGS::=". I > > > checked the syntax with the OSS tools and didn't find a problem. > > > - (Re. 6) I believe this was brought in through MSF and I never > > > checked. Having looked up Q.2941.1 now, I agree that 4 octets is > > > restrictive. > > > > > > John > > > > > > "Drage, Keith" wrote: > > > > > > > > Attached please find a number of editorial comments on the Geneva output > > > > document, which we also understand is identical to the MEGACO last call > > > > document. These points are not intended to be controversial. In the event > > > > that discussion is required to resolve such a comment, then we will withdraw > > > > the comment in order to allow the document to proceed. > > > > > > > > 1) Abbreviations. "BRI" is never used and therefore should be removed > > > > from the list of abbreviations. > > > > > > > > 2) References. Q.724 is never used and should be removed. > > > > > > > > 3) References and annex C. Where a reference is only used in annex C, > > > > we believe in general in most cases these should be undated (i.e. the latest > > > > version of the referenced document applies). This in particular applies to > > > > Q.931, Q. 2931, Q.763 where ITU-T SG11 have no intention of changing > > > > codepoints to different values, but do reserve the right to add new values. > > > > Surely the whole ethos of annex C is that new values do get automatically > > > > incorporated. > > > > > > > > 4) References (and annex C if comment 3 not accepted). Some of the > > > > dates are incorrect. Q.761-4 have a date of December 1999 as that was > > > > decided last year. Q.2931 should reflect the date of the latest amendment > > > > (4) which we believe is also December 1999. > > > > > > > > 5) Annex A. We could not find the module header, or an exports > > > > statement, for the ASN.1. The module header is mandatory parts of the ASN.1, > > > > and gives that module an object identifier, which is needed for inport to > > > > anything else. > > > > > > > > 6) Annex C, C.8, generic identifier transport. We are not sure how you > > > > fit this into four octets. Is there some subset of the generic identifier > > > > transport information element that is being used? Various codings of this > > > > information element get very, very long. > > > > > > > > 7) Annex C, C.9, ITC has a reference to a note 2, which is not in the > > > > table. Is this a spurious inport from the referenced standard? If so, we > > > > believe it can be deleted. > > > > > > > > 8) Annex C, C.9. References to Q.931 need to identify that the > > > > references are to the encoding in the Bearer capability information element, > > > > and not to the Low layer information element. The latter has identical > > > > fields with the same code values, but has a more extensive range of values > > > > assigned. This is because some values (particularly at layer 3) are only > > > > defined for end user to addressed end user usage. I believe in H.248 only > > > > the more restricted list in the Bearer capability information element would > > > > be valid. > > > > > > > > Keith Drage > > > > > > > > > --------------------------------------------------------------- > > > > > Keith Drage (keith.drage@siemenscomms.co.uk) > > > > > Siemens Communications Limited, > > > > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > > > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > > > > --------------------------------------------------------------- > > > > > Internet communications are not secure and therefore Siemens > > > > > Communications Limited does not accept legal responsibility for the > > > > > contents of this message. Any views or opinions presented are solely those > > > > > of the author and do not necessarily represent those of Siemens > > > > > Communications Limited unless otherwise specifically stated. > > > > > > > > > > > > > > > > -- > > > John Segers email: jsegers@lucent.com > > > Lucent Technologies Room HE 306 > > > Dept. Forward Looking Work phone: +31 35 687 4724 > > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 306 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 16 16:09:27 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19306 for ; Thu, 16 Mar 2000 16:09:27 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4CF61AA0@standards.nortelnetworks.com>; Thu, 16 Mar 2000 16:04:25 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 91674 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 16 Mar 2000 16:03:24 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C24DD8D0@standards.nortelnetworks.com>; Thu, 16 Mar 2000 15:53:23 -0500 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id MAA19280; Thu, 16 Mar 2000 12:57:07 -0800 (PST) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: multipart/alternative; boundary="------------1D9A9E99CB49DE19223AC2C4" Message-ID: <38D17563.9187773B@cisco.com> Date: Thu, 16 Mar 2000 15:59:31 -0800 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Subject: Re: On 7.1.4 X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM --------------1D9A9E99CB49DE19223AC2C4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tom-PT Taylor wrote: > > > Responses below. > > -----Original Message----- > From: Flemming Andreasen [SMTP:fandreas@CISCO.COM] > Sent: Saturday, March 11, 2000 11:47 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: On 7.1.4 > > Tom Taylor wrote: > > > > > > 7) 7.1.14, last sentence in paragraph beginning with "The > letter 'x' > > is > > > used as a wildcard..." specifies that "As a consequence of > the thrid > > > > > timing rule above, inter-event timing while matching the dot > symbol > > uses > > > the short timer by default." is incorrect. The grammar may > continue > > past > > > the dot symbol implying the dot could only possibly produce a > > > partial > > > match which furthermore implies that the short timer may not > be the > > > right one to use. The sentence should simply be removed. > > [[TomT]] Agreed that the grammar may continue past the > dot, > > but > > until you get that far you have an ambiguous situation -- you > don't > > know how > > many events will be mapped into the dot. The sentence is > correct > > AFAIK. > > That's not entirely accurate, e.g. consider "x.#" Now, if what > follows > the dot has a non-empty intersection with what precedes the dot > (ignoring timers), you have an ambigous situation. In that case > you > could then apply the short timer, or alternatively simply leave > the > timing rules undefined then (since you can always rewrite the > digit map > to avoid this, well at least in most cases). > [[TomT]] > The term "ambiguous" is used in this section to mean that > multiple patterns in the digit map match the current dial > string. The pattern "x.F" (not "x.#") is a short way of > specifying a whole series of patterns: "xF" | "xxF" | "xxxF" | > ... This is why I say that the dot creates an ambiguous > situation which calls for the use of the short timer. At any > point in the dialling process short of receiving the final #, > there is an indefinite number of patterns which the current dial > string may match. > That still doesn't sound right as it would imply that if I had say "12 | 13" in my digit map then upon entering 1, I would apply short interdigit timing. The only thing that makes ambigouity interesting, is when you *cannot* determine whether there is a match or not. The way you determine that is then to apply a short interdigit timer, otherwise a long timer is applied. > > > > > > > > > > 8) 7.1.14, next paragraph specifies that "A timer specified > > following a > > > dot specifies inter-event timing for all events matching the > dot as > > well > > > as for subsequent events". It's unclear why the timer > couldn't > > simply be > > > put in front of the dot and thereby be consistent with digit > map > > timers > > > in general. In the absence of a compelling argument the > sentence > > should > > > simply be removed. > > [[TomT]] Same problem as with the previous remark -- > you > > don't know > > when you've gone past the dot until it's too late. If there is > a > > timer both > > before and after the dot, a timer after the dot never gets > used. It > > may be > > better just to say that, I suppose, leaving it up to the MGC to > set a > > timer > > before the dot if it wants. > > You could have have "S.xL", but otherwise I agree. > [[TomT]] > At this point I see that my remarks were a little imprecise: if > there is a timer both before and IMMEDIATELY after the dot, the > timer after the dot doesn't get used to detect the event that > indicates that the dot has been passed. It may apply to events > subsequent to that point. > Even that may not be entirely accurate (although it in practice is probably not a big deal), e.g. consider "S.xLF". > > > > > > > > > 9) 7.1.14, numbered list, item 4: The second sentence and > the > > last > > > sentence seem to contradict each other. While absence of > > long-duration > > > may prevent a match from occurring, existence of > long-duration > > should > > > not. Consequently, the second sentence is what should be > modified. > > [[TomT]] I assume you mean the last sentence of the > > paragraph. You > > will reach this case only if all of the alternatives specifying > a > > long-duration event at this point have been discarded. Thus > duration > > becomes irrelevant, but only after it has been taken into > account in > > the > > cases where it mattered. > > OK, I think I understand now, however the rule then seems to be > incorrect. Consider the digit map "Zx1 | x2" with input "Z1". The > way I > read rule 4, the second sentence would lead us to discard > alternative > "x2" which doesn't seem like the right thing to do, since "x2" > doesn't > prevent us from having a long event, right ? > [[TomT]] > My reasoning in putting the rules together was that by specifying > a long-duration event in a given position you were saying that > duration really mattered at that point and should be used as a > discriminator between candidate patterns. I think the logic of > that position is still reasonable, but quite theoretical. It > really comes down to whether the rule prevents you from doing the > right thing in practical situations. > Fair enough. I think you are right that it will not be an issue in practice. > > > > > > > > > 10) 7.1.14, numbered list, item 5 specifies that "If exactly > one > > > candidate remains, a completion event is generated indicating > an > > > unambiguous match". This seems to imply that even a partial > match > > (as > > > long as there is only one) will result in a digit map > completion > > event, > > > which of course is incorrect. > > [[TomT]] Good catch. This really is an error. We > should > > change > > that to "If exactly one candidate remains and it is fully > matched, > > ..." > > > > > 11) 7.1.14, numbered list, item 5: It is entirely unclear > why an > > > event triggering a partial match is not reported as part of > the > > matched > > > string. In the absence of a compelling argument, the > triggering > > event > > > should be included in the string as it otherwise may be > processed > > twice, > > > which is hardly what the user had in mind. > > [[TomT]] I had it that way in the first place (with > the > > triggering > > event distinguished by being placed in an "extra event" > parameter) and > > > > consensus was to change it to what it is now. Have to overrule > you on > > this > > one unless you get more support. > > Well, I think it would be more appropriate that those who argue > against > explain why. There's got to be a reasonable explanation here, or > reviewing this stuff is a waste of everybody's time. > [[TomT]] > The reasoning was that when you activate a digit map it's what > the digit map matches that is of interest -- anything left over > needs to be handled in a separate processing step. The typical > situation in our experience is that digit collection happens in > multiple stages. The MGC doesn't want to receive that extra > digit because it wants the digit to be processed against the next > map to be activated. > Agreed, but only in the case where the first stage did not contain an error, i.e. mismatch. You want to consume the "error" input. > > > I'll have to think about the "double processing" question. > Events have side effects, such as stopping signals, and clearly > we only want those side effects to happen once. It may be that > we need language to make sure this is what happens. > > > I'm also not clear how you get duplicate > > processing -- the situation is logically equivalent to the > triggering > > event > > (a non-matching digit) happening just after the digit > completion event > > has > > been notified. > > Consider an IVR menu where input consists of two or more digits. > For > sake of argument, let's say the only valid choice is "12", and I > erroneously enter "13". Upon entering "3" we get a mismatch and I > > probably hear a recording telling me that "13" is an invalid > choice and > I should try again. > [[TomT]] > More likely you'll get a recording telling you what the valid > choices are. Under our current rules, of course, the MGC doesn't > know about the 3 when the digit map completion event is reported. > > When digit map processing resumes for renewed input, > "3" will now be processed and I get another mismatch. > [[TomT]] > Seems clear in this case that the MGC should ensure that the > event buffer is cleared before resuming the operation. > Agreed, however LockStep doesn't do that, so you have a problem. > > > The event was > processed twice which is the problem (a "process"/"discard" > parameter in > event handling would of course be a general cure for such > problems, but > alas, that was not to happen) > > > > > > > > > 12) 7.1.14, second last paragraph states that "Regardles of > whether > > a > > > digit map is activated, this form of event specification will > cause > > the > > > individual events to be reported to the MGC as they are > detected". > > Some > > > clarification is requested here. > > [[TomT]] This paragraph gives the interpretation of > e.g. the > > "dd/*" > > event specification. Using the example digit map which > immediately > > follows, > > a dialled "1" will be reported immediately and also accumulated > into > > the > > digit map. Of course, if EventBufferControl is set to > LockStep, the > > digit > > map will never complete because a new Event Descriptor will be > loaded > > before > > completion can be reported. (There is a corner case with a > dialled > > "0" and > > short timer expiry before the new Event descriptor is loaded, > but > > let's not > > go into that.) > > I can, to some extent, understand that, although I think this > dual > processing does little but underscore the lack of generality in > the > event handling scheme (interesting case when you have > EventBufferControl > off). At a bare minimum I think you should define that an event > detected > can at most match or be consumed by a single "event" specified in > the > EventsDescriptor. > > What I don't understand in the above sentence is, that it seems > to imply > that the name by which we refer to an event impacts the reporting > of > that event. With the current "dd" package, you may request digit > map > matching without by only requesting the "Digit Map Completion" > event, > i.e. do not request DTMF digits (correct ?). Thus I might define > another > package, call it "dd2" that only consists of this particular > event. What > the above sentence now implies is, that when I request "dd/ce", I > will > process according to the digit map, but when I request "dd/*", > which can > only expand to "dd/ce", I will report the digits invidually. > Doesn't > seem right. > [[TomT]] It seems like you typed this one a bit quickly. > Yes, the example should of course have referred to "dd2" instead of "dd". > The problem is that dd/* currently includes within its scope both > the individual digit events and the digit map completion event. > If you moved the latter off to an extension package dd2, then I > think we would have: > > - dd/* reports only individual digit events > - dd2/* reports only the digit map completion event. > Agreed (report most specific event). The current sentence does not seem to imply this though unless you qualify it to specifically only reference the "dd" package. -- Flemming --------------1D9A9E99CB49DE19223AC2C4 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Tom-PT Taylor wrote:

 

Responses below.

    -----Original Message-----
    From:  Flemming Andreasen [SMTP:fandreas@CISCO.COM]
    Sent:  Saturday, March 11, 2000 11:47 AM
    To:    MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       On 7.1.4

    Tom Taylor wrote:

    >
    > > 7) 7.1.14, last sentence in paragraph beginning with "The letter 'x'
    > is
    > > used as a wildcard..." specifies that "As a consequence of the thrid
    >
    > > timing rule above, inter-event timing while matching the dot symbol
    > uses
    > > the short timer by default." is incorrect. The grammar may continue
    > past
    > > the dot symbol implying the dot could only possibly produce a
    > partial
    > > match which furthermore implies that the short timer may not be the
    > > right one to use. The sentence should simply be removed.
    >         [[TomT]]  Agreed that the grammar may continue past the dot,
    > but
    > until you get that far you have an ambiguous situation -- you don't
    > know how
    > many events will be mapped into the dot.  The sentence is correct
    > AFAIK.

    That's not entirely accurate, e.g. consider "x.#" Now, if what follows
    the dot has a non-empty intersection with what precedes the dot
    (ignoring timers), you have an ambigous situation. In that case you
    could then apply the short timer, or alternatively simply leave the
    timing rules undefined then (since you can always rewrite the digit map
    to avoid this, well at least in most cases).
    [[TomT]]
    The term "ambiguous" is used in this section to mean that multiple patterns in the digit map match the current dial string.  The pattern "x.F" (not "x.#") is a short way of specifying a whole series of patterns: "xF" | "xxF" | "xxxF" | ...  This is why I say that the dot creates an ambiguous situation which calls for the use of the short timer.  At any point in the dialling process short of receiving the final #, there is an indefinite number of patterns which the current dial string may match.

That still doesn't sound right as it would imply that if I had say "12 | 13" in my digit map then upon entering 1, I would apply short interdigit timing. The only thing that makes ambigouity interesting, is when you *cannot* determine whether there is a match or not. The way you determine that is then to apply a short interdigit timer, otherwise a long timer is applied.
     

    >

    >
    > > 8) 7.1.14, next paragraph specifies that "A timer specified
    > following a
    > > dot specifies inter-event timing for all events matching the dot as
    > well
    > > as for subsequent events". It's unclear why the timer couldn't
    > simply be
    > > put in front of the dot and thereby be consistent with digit map
    > timers
    > > in general. In the absence of a compelling argument the sentence
    > should
    > > simply be removed.
    >         [[TomT]]  Same problem as with the previous remark -- you
    > don't know
    > when you've gone past the dot until it's too late.  If there is a
    > timer both
    > before and after the dot, a timer after the dot never gets used.  It
    > may be
    > better just to say that, I suppose, leaving it up to the MGC to set a
    > timer
    > before the dot if it wants.

    You could have have "S.xL", but otherwise I agree.
    [[TomT]]
    At this point I see that my remarks were a little imprecise: if there is a timer both before and IMMEDIATELY after the dot, the timer after the dot doesn't get used to detect the event that indicates that the dot has been passed.  It may apply to events subsequent to that point.

Even that may not be entirely accurate (although it in practice is probably not a big deal), e.g. consider "S.xLF".
     

    >
    >
    > > 9) 7.1.14, numbered list, item 4:    The second sentence and the
    > last
    > > sentence seem to contradict each other. While absence of
    > long-duration
    > > may prevent a match from occurring, existence of long-duration
    > should
    > > not. Consequently, the second sentence is what should be modified.
    >         [[TomT]]  I assume you mean the last sentence of the
    > paragraph.  You
    > will reach this case only if all of the alternatives specifying a
    > long-duration event at this point have been discarded.  Thus duration
    > becomes irrelevant, but only after it has been taken into account in
    > the
    > cases where it mattered.

    OK, I think I understand now, however the rule then seems to be
    incorrect. Consider the digit map "Zx1 | x2" with input "Z1". The way I
    read rule 4, the second sentence would lead us to discard alternative
    "x2" which doesn't seem like the right thing to do, since "x2" doesn't
    prevent us from having a long event, right ?
    [[TomT]]
    My reasoning in putting the rules together was that by specifying a long-duration event in a given position you were saying that duration really mattered at that point and should be used as a discriminator between candidate patterns.  I think the logic of that position is still reasonable, but quite theoretical.  It really comes down to whether the rule prevents you from doing the right thing in practical situations.

Fair enough. I think you are right that it will not be an issue in practice.
     

    >
    >
    > > 10) 7.1.14, numbered list, item 5 specifies that "If exactly one
    > > candidate remains, a completion event is generated indicating an
    > > unambiguous match". This seems to imply that even a partial match
    > (as
    > > long as there is only one) will result in a digit map completion
    > event,
    > > which of course is incorrect.
    >         [[TomT]]  Good catch.  This really is an error.  We should
    > change
    > that to "If exactly one candidate remains and it is fully matched,
    > ..."
    >
    > > 11) 7.1.14, numbered list, item 5:    It is entirely unclear why an
    > > event triggering a partial match is not reported as part of the
    > matched
    > > string. In the absence of a compelling argument, the triggering
    > event
    > > should be included in the string as it otherwise may be processed
    > twice,
    > > which is hardly what the user had in mind.
    >         [[TomT]]  I had it that way in the first place (with the
    > triggering
    > event distinguished by being placed in an "extra event" parameter) and
    >
    > consensus was to change it to what it is now.  Have to overrule you on
    > this
    > one unless you get more support.

    Well, I think it would be more appropriate that those who argue against
    explain why. There's got to be a reasonable explanation here, or
    reviewing this stuff is a waste of everybody's time.
    [[TomT]]
    The reasoning was that when you activate a digit map it's what the digit map matches that is of interest -- anything left over needs to be handled in a separate processing step.  The typical situation in our experience is that digit collection happens in multiple stages.  The MGC doesn't want to receive that extra digit because it wants the digit to be processed against the next map to be activated.

Agreed, but only in the case where the first stage did not contain an error, i.e. mismatch. You want to consume the "error" input.
     

    I'll have to think about the "double processing" question.  Events have side effects, such as stopping signals, and clearly we only want those side effects to happen once.  It may be that we need language to make sure this is what happens.

    > I'm also not clear how you get duplicate
    > processing -- the situation is logically equivalent to the triggering
    > event
    > (a non-matching digit) happening just after the digit completion event
    > has
    > been notified.

    Consider an IVR menu where input consists of two or more digits. For
    sake of argument, let's say the only valid choice is "12", and I
    erroneously enter "13". Upon entering "3" we get a mismatch and I
    probably hear a recording telling me that "13" is an invalid choice and
    I should try again.
    [[TomT]]
    More likely you'll get a recording telling you what the valid choices are.  Under our current rules, of course, the MGC doesn't know about the 3 when the digit map completion event is reported.

    When digit map processing resumes for renewed input,
    "3" will now be processed and I get another mismatch.
    [[TomT]]
    Seems clear in this case that the MGC should ensure that the event buffer is cleared before resuming the operation.

Agreed, however LockStep doesn't do that, so you have a problem.
     

    The event was
    processed twice which is the problem (a "process"/"discard" parameter in
    event handling would of course be a general cure for such problems, but
    alas, that was not to happen)
     

    >
    >
    > > 12) 7.1.14, second last paragraph states that "Regardles of whether
    > a
    > > digit map is activated, this form of event specification will cause
    > the
    > > individual events to be reported to the MGC as they are detected".
    > Some
    > > clarification is requested here.
    >         [[TomT]]  This paragraph gives the interpretation of e.g. the
    > "dd/*"
    > event specification.  Using the example digit map which immediately
    > follows,
    > a dialled "1" will be reported immediately and also accumulated into
    > the
    > digit map.  Of course, if EventBufferControl is set to LockStep, the
    > digit
    > map will never complete because a new Event Descriptor will be loaded
    > before
    > completion can be reported.  (There is a corner case with a dialled
    > "0" and
    > short timer expiry before the new Event descriptor is loaded, but
    > let's not
    > go into that.)

    I can, to some extent, understand that, although I think this dual
    processing does little but underscore the lack of generality in the
    event handling scheme (interesting case when you have EventBufferControl
    off). At a bare minimum I think you should define that an event detected
    can at most match or be consumed by a single "event" specified in the
    EventsDescriptor.

    What I don't understand in the above sentence is, that it seems to imply
    that the name by which we refer to an event impacts the reporting of
    that event. With the current "dd" package, you may request digit map
    matching without by only requesting the "Digit Map Completion" event,
    i.e. do not request DTMF digits (correct ?). Thus I might define another
    package, call it "dd2" that only consists of this particular event. What
    the above sentence now implies is, that when I request "dd/ce", I will
    process according to the digit map, but when I request "dd/*", which can
    only expand to "dd/ce", I will report the digits invidually. Doesn't
    seem right.
    [[TomT]]  It seems like you typed this one a bit quickly.

Yes, the example should of course have referred to "dd2" instead of "dd".
    The problem is that dd/* currently includes within its scope both the individual digit events and the digit map completion event.  If you moved the latter off to an extension package dd2, then I think we would have:

     - dd/* reports only individual digit events
     - dd2/* reports only the digit map completion event.

Agreed (report most specific event). The current sentence does not seem to imply this though unless you qualify it to specifically only reference the "dd" package.

-- Flemming
  --------------1D9A9E99CB49DE19223AC2C4-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 16 16:15:15 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21659 for ; Thu, 16 Mar 2000 16:15:14 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.24D2E070@standards.nortelnetworks.com>; Thu, 16 Mar 2000 16:10:27 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 91675 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 16 Mar 2000 16:08:41 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7FBEB420@standards.nortelnetworks.com>; Thu, 16 Mar 2000 15:58:41 -0500 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id NAA21600; Thu, 16 Mar 2000 13:02:48 -0800 (PST) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: multipart/alternative; boundary="------------CA00E295748F620E3499BA4B" Message-ID: <38D176B0.25628F3B@cisco.com> Date: Thu, 16 Mar 2000 16:05:04 -0800 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Subject: Re: Comments on draft-ietf-megaco-protocol-07 X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM --------------CA00E295748F620E3499BA4B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tom-PT Taylor wrote: > > > Responses couple of open items from your original note. > > -----Original Message----- > From: Flemming Andreasen [SMTP:fandreas@CISCO.COM] > Sent: Friday, March 10, 2000 7:10 PM > > > 24) D.1.4, last paragraph specifies that "Upon receipt of of > a final > > > response, an immediate confirmation shall be sent, and normal > repetition > > > timers shall be used thereafter", however it is not specified > how the > > > entity determines whether the final response needs to be > confirmed > > > immediately or not (consider the case where the pending was > lost). A > > > specification for this needs to be added. > > Didn't see a response here. > [[TomT]] > Agreed that the behaviour of an MGC that receives a Transaction > Pending may differ from that of an MGC which does not when the > final response comes, but any possible tightening of the > conditions for immediate acknowledgement of final responses > (e.g. do it whenever the original transaction has been sent more > than once) is just a bit of optimization. It potentially > generates an extra message from the MGC to prevent an extra final > Transaction Response from the MG. > It's actually worse than that. Since the transaction initiator *shall* confirm this final response, consider what happens if the pending got lost, and the final did not. The transaction initiator has no idea that it's supposed to confirm this message, however the responder, expecting a confirmation it will never get will be resending this final response until it eventually gives up and probably concludes that something's wrong. What you need is some kind of indication in the final response instructing the receiver that it *must* confirm this response. > > > > > > > > > > 25) D.1.5, last paragraph specifies that "When the MG > establishes a new > > > control association, it can retransmit to the new MGC. > Alternatively, a > > > MG may use a ServiceChange with ServiceChangeMethod equal to > > > disconnected to inform the new MGC that the MG lost one or > more > > > transaction". In order to prevent duplicate transactions, it > must be > > > required that transactions cannot be retransmitted T-MAX time > after > > > their initial transmission. Consequently, a disconnected > ServiceChange > > > *must* be issued in such cases. > > Didn't see a response here. > [[TomT]] > There is a problem with this paragraph -- "establishes a new > control association" hides detail that should have been spelled > out. > > That detail is which ServiceChangeMethod to use in the process. > And as you say, that must be "Disconnected". > -- Flemming --------------CA00E295748F620E3499BA4B Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Tom-PT Taylor wrote:

 

Responses couple of open items from your original note.

    -----Original Message-----
    From:   Flemming Andreasen [SMTP:fandreas@CISCO.COM]
    Sent:   Friday, March 10, 2000 7:10 PM
    > > 24) D.1.4, last paragraph specifies that "Upon receipt of of a final
    > > response, an immediate confirmation shall be sent, and normal repetition
    > > timers shall be used thereafter", however it is not specified how the
    > > entity determines whether the final response needs to be confirmed
    > > immediately or not (consider the case where the pending was lost). A
    > > specification for this needs to be added.

    Didn't see a response here.
    [[TomT]]
    Agreed that the behaviour of an MGC that receives a Transaction Pending may differ from that of an MGC which does not when the final response comes, but any possible tightening of the conditions for immediate acknowledgement of final responses (e.g.  do it whenever the original transaction has been sent more than once) is just a bit of optimization.  It potentially generates an extra message from the MGC to prevent an extra final Transaction Response from the MG.

It's actually worse than that. Since the transaction initiator *shall* confirm this final response, consider what happens if the pending got lost, and the final did not. The transaction initiator has no idea that it's supposed to confirm this message, however the responder, expecting a confirmation it will never get will be resending this final response until it eventually gives up and probably concludes that something's wrong. What you need is some kind of indication in the final response instructing the receiver that it *must* confirm this response.
     

    >
    > >
    > > 25) D.1.5, last paragraph specifies that "When the MG establishes a new
    > > control association, it can retransmit to the new MGC. Alternatively, a
    > > MG may use a ServiceChange with ServiceChangeMethod equal to
    > > disconnected to inform the new MGC that the MG lost one or more
    > > transaction". In order to prevent duplicate transactions, it must be
    > > required that transactions cannot be retransmitted T-MAX time after
    > > their initial transmission. Consequently, a disconnected ServiceChange
    > > *must* be issued in such cases.

    Didn't see a response here.
    [[TomT]]
    There is a problem with this paragraph -- "establishes a new control association" hides detail that should have been spelled out.

    That detail is which ServiceChangeMethod to use in the process.  And as you say, that must be "Disconnected".


-- Flemming --------------CA00E295748F620E3499BA4B-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 16 18:17:19 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07699 for ; Thu, 16 Mar 2000 18:17:19 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.384FD430@standards.nortelnetworks.com>; Thu, 16 Mar 2000 18:12:41 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 91824 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 16 Mar 2000 18:11:24 -0500 Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.09FF4AC0@standards.nortelnetworks.com>; Thu, 16 Mar 2000 18:11:24 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id AAA25292; Fri, 17 Mar 2000 00:15:39 +0100 (MET) 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 AAA12022; Fri, 17 Mar 2000 00:15:38 +0100 (MET) Received: from ericsson.com (rac175pc.edd.ericsson.se [164.48.123.175]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id AAA11027; Fri, 17 Mar 2000 00:15:16 +0100 (MET) X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <852568A4.0050AE6C.00@notes950.cc.telcordia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38D15F82.5C3BBF29@ericsson.com> Date: Thu, 16 Mar 2000 23:26:11 +0100 Reply-To: Stephen Terrill Sender: "Media Gateway Control (megaco)" From: Stephen Terrill Organization: L.M. Ericsson Subject: Re: Comments on MEGACO protocol X-To: Selvam Rengasami To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, The reason that this suggestion was not followed in the first place was for reasons of the referencing rules. A determined document is not allowed to reference a not determined document (like an RFC reference and I-D). I am not sure of the timing of the SG-11 decision cf the SG-16 decision of H.248. If it allows for this, then it might be OK, otherwise other solutions should be sought. Selvam Rengasami wrote: > Folks, > > One correction to my previous e-mail. > > If we accept my proposal, then we should consider changing the reference from > Q.2941.1 to Q.2941.3 in C.8 > > Cheers, > > -Selvam > > Selvam Rengasami on 03/16/2000 09:41:23 AM > > Please respond to Selvam Rengasami > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: (bcc: Selvam Rengasami/Telcordia) > Subject: Re: Comments on MEGACO protocol > > Christian, John, > > I think the issue that Keith is raising is an interesting one. Q.2941.1 defines > a generic mechanism for transporting an identifier via the GIT in DSS2. As > Keith points out, in general, the GIT length is not limited by Q.2941.1, > therefore 4 or even 6 octets is not enough, if we want to support the generic > mechanism. > > Now, if we want to support the BNC-ID mechanism (e.g., for use in conjunction > with BICC), then Q.2941.3 defines how a BNC-ID is carried in the GIT. Q.2941.3 > constrains the GIT length for BNC-ID value to exactly four octets (no more, no > less). Specifically, Q.2941.3 gives the coding for Octet 5 (which identifies > BICC [Q.1901] and for Octet 6 indicates that the identifier is a BNC-ID. In > addition, Octet 6.1 (the length of the identifier) is required to be coded to a > value of 4. Finally octets 6.2 through 6.5 provide the four octet BNC-ID value. > > If we want to allow for future variations in Q.2941.3 or even Q.2941.1, then we > may want to consider allowing more than four octets for the BIR in C.8. > > I am basically interested in having the BNC-ID value (as defined by Q.2941.3) > signaled between the MGC and the MG. Four octets would suffice for this > purpose. I propose that we agree that the BIR for C.8 can only contain the > BNC-ID value as defined in Q.2941.3 (i.e., octets 6.2 through 6.5) which > requires no change to the document. > > By the way, Q.2941.3 (along with the other BICC related standards) is scheduled > to be approved (decided) in the Special meeting of SG 11 on June 15. > > Cheers, > > -Selvam Rengasami > > Telcordia Technologies > > Tel: +1 732 758 5260 > E-mail: srengasa@telcordia.com > > Christian Groves on 03/15/2000 06:58:59 PM > > Please respond to Christian Groves > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: (bcc: Selvam Rengasami/Telcordia) > Subject: Re: Comments on MEGACO protocol > > G'Day John, > > The property name is BIR. > > Perhaps the following change might work? > > BNCid 8000 6 OCTETS GIT (Generic Identifier Transport) > BNCid (Octet 5a and above) > Ref.: Recommendation Q.2941.1 (09/97) > > Cheers, Christian > > John Segers wrote: > > > > Christian, > > > > I believe it makes sense when it is used for binding reference. If we > > only use octet 5 and above, and only use the GIT parameter for this > > specific case, we should rethink the name of the parameter. Using GIT > > with a reference to Q.2941.1 will undoubtedly lead to confusion. > > > > John > > > > Christian Groves wrote: > > > > > > G'Day Keith and John, > > > > > > Regarding 6 the intention was to use this as a binding reference > > > (BNCid). Annex C should refer to octet 5 and above. For the BNCid the > > > length as per the GIT would be 6 octets. Make sense? > > > > > > Cheers, Christian > > > > > > John Segers wrote: > > > > > > > > Keith, > > > > > > > > Most of the changes you request are ok. There's a couple that I don't > > > > know about: > > > > - (Re. 3) I thought that references to ITU Rec. have to be specific > > > > (i.e., including a date). I asked Glen, and he's not sure either. > > > > We'll check. > > > > - (Re. 5) What headers are missing according to you? The current ASN.1 > > > > starts with "MEDIA-GATEWAY-CONTROL DEFINITIONS AUTOMATIC TAGS::=". I > > > > checked the syntax with the OSS tools and didn't find a problem. > > > > - (Re. 6) I believe this was brought in through MSF and I never > > > > checked. Having looked up Q.2941.1 now, I agree that 4 octets is > > > > restrictive. > > > > > > > > John > > > > > > > > "Drage, Keith" wrote: > > > > > > > > > > Attached please find a number of editorial comments on the Geneva output > > > > > document, which we also understand is identical to the MEGACO last call > > > > > document. These points are not intended to be controversial. In the > event > > > > > that discussion is required to resolve such a comment, then we will > withdraw > > > > > the comment in order to allow the document to proceed. > > > > > > > > > > 1) Abbreviations. "BRI" is never used and therefore should be > removed > > > > > from the list of abbreviations. > > > > > > > > > > 2) References. Q.724 is never used and should be removed. > > > > > > > > > > 3) References and annex C. Where a reference is only used in annex > C, > > > > > we believe in general in most cases these should be undated (i.e. the > latest > > > > > version of the referenced document applies). This in particular applies > to > > > > > Q.931, Q. 2931, Q.763 where ITU-T SG11 have no intention of changing > > > > > codepoints to different values, but do reserve the right to add new > values. > > > > > Surely the whole ethos of annex C is that new values do get > automatically > > > > > incorporated. > > > > > > > > > > 4) References (and annex C if comment 3 not accepted). Some of the > > > > > dates are incorrect. Q.761-4 have a date of December 1999 as that was > > > > > decided last year. Q.2931 should reflect the date of the latest > amendment > > > > > (4) which we believe is also December 1999. > > > > > > > > > > 5) Annex A. We could not find the module header, or an exports > > > > > statement, for the ASN.1. The module header is mandatory parts of the > ASN.1, > > > > > and gives that module an object identifier, which is needed for inport > to > > > > > anything else. > > > > > > > > > > 6) Annex C, C.8, generic identifier transport. We are not sure how > you > > > > > fit this into four octets. Is there some subset of the generic > identifier > > > > > transport information element that is being used? Various codings of > this > > > > > information element get very, very long. > > > > > > > > > > 7) Annex C, C.9, ITC has a reference to a note 2, which is not in > the > > > > > table. Is this a spurious inport from the referenced standard? If so, we > > > > > believe it can be deleted. > > > > > > > > > > 8) Annex C, C.9. References to Q.931 need to identify that the > > > > > references are to the encoding in the Bearer capability information > element, > > > > > and not to the Low layer information element. The latter has identical > > > > > fields with the same code values, but has a more extensive range of > values > > > > > assigned. This is because some values (particularly at layer 3) are only > > > > > defined for end user to addressed end user usage. I believe in H.248 > only > > > > > the more restricted list in the Bearer capability information element > would > > > > > be valid. > > > > > > > > > > Keith Drage > > > > > > > > > > > --------------------------------------------------------------- > > > > > > Keith Drage (keith.drage@siemenscomms.co.uk) > > > > > > Siemens Communications Limited, > > > > > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > > > > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > > > > > --------------------------------------------------------------- > > > > > > Internet communications are not secure and therefore Siemens > > > > > > Communications Limited does not accept legal responsibility for the > > > > > > contents of this message. Any views or opinions presented are solely > those > > > > > > of the author and do not necessarily represent those of Siemens > > > > > > Communications Limited unless otherwise specifically stated. > > > > > > > > > > > > > > > > > > > > -- > > > > John Segers email: jsegers@lucent.com > > > > Lucent Technologies Room HE 306 > > > > Dept. Forward Looking Work phone: +31 35 687 4724 > > > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > > > > -- > > John Segers email: jsegers@lucent.com > > Lucent Technologies Room HE 306 > > Dept. Forward Looking Work phone: +31 35 687 4724 > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 16 19:55:27 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13788 for ; Thu, 16 Mar 2000 19:55:26 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EDE61D10@standards.nortelnetworks.com>; Thu, 16 Mar 2000 19:50:49 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 91919 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 16 Mar 2000 19:49:18 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.51AFAF70@standards.nortelnetworks.com>; Thu, 16 Mar 2000 19:39:18 -0500 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id QAA12919; Thu, 16 Mar 2000 16:43:32 -0800 (PST) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <4.2.2.20000313172117.00a66de0@dogwood.cisco.com> <38CE4D0F.A514434F@americasm01.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38D1AA75.843C39D6@cisco.com> Date: Thu, 16 Mar 2000 19:45:57 -0800 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Subject: Re: Descriptor processing order X-To: Abdallah Rayhan To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Sounds good to me. -- Flemming Abdallah Rayhan wrote: > I believe there is an agreement that commands are atomic, either > succeed or fail and no partial commands. but I agree with you that > there is no text, up to my knowledge, saying that descriptors are > attempted in order. The closest we get to this is in Section 8, > "Transactions guarantee ordered Command processing. That is, Commands > within a Transaction are executed sequentially. Ordering of Transactions is > NOT guaranteed - transactions may be executed in any order, or > simultaneously." > > I propose adding the following sentence to the above paragraph, > " All commands are atomic operations, either succeed or fail as a whole, > and descriptors within commands are processed in sequence of their > order." > > Abdallah Rayhan > > Chip Sharp wrote: > > > Due to a previous question on event handling, I went through the output of > > SG16 (TD37) looking for text on the ordering of processing of descriptors. > > > > However, I could find no text in the document that describes in what order > > a MG or MGC should process descriptors. I was specifically wondering if > > the TerminationStateDescriptor was processed before the > > EventsDescriptor. This has implications in that the order of processing > > the value of the EventBufferControl parameter in the > > TerminationStateDescriptor and the EventsDescriptor will affect how events > > in the EventBuffer are processed. > > > > If TerminationStateDescriptor is processed first and EventBufferControl=Off > > (previous LockStep), then all events are discarded. If EventsDescriptor is > > processed first then at least one more event will be reported before the > > EventBuffer is flushed (ignoring the previous discussion as to whether this > > is desirable or not). > > > > It seems there may be any number of conditions like this that will depend > > on ordering of processing of descriptors in the command. > > > > Shouldn't there be some basic text in the spec that either specifies that > > the receiver of a command should process the descriptors in the order > > received or that the receiver can process them in any order desired? I > > prefer the former. The latter seems a little indeterminate. > > > > If there is already text of this nature in the document, please educate me > > as to its location. > > > > Thanks, > > Chip > > Support NetAid! http://www.netaid.org > > -------------------------------------------------- > > Chip Sharp Consulting Engineering > > Cisco Systems Telco Bio-region > > Reality - Love it or Leave it. > > -------------------------------------------------- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 16 21:20:36 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16875 for ; Thu, 16 Mar 2000 21:20:36 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D0F08400@standards.nortelnetworks.com>; Thu, 16 Mar 2000 21:15:55 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 91977 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 16 Mar 2000 21:14:20 -0500 Received: from dnsmx2pya.telcordia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.98091A30@standards.nortelnetworks.com>; Thu, 16 Mar 2000 21:14:19 -0500 Received: from notes950.cc.telcordia.com (notes950.cc.telcordia.com [128.96.244.1]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with SMTP id VAA19041; Thu, 16 Mar 2000 21:16:18 -0500 (EST) Received: by notes950.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852568A5.000C79F6 ; Thu, 16 Mar 2000 21:16:16 -0500 X-Lotus-FromDomain: TELCORDIA Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <852568A5.000C7908.00@notes950.cc.telcordia.com> Date: Thu, 16 Mar 2000 21:18:49 -0500 Reply-To: Selvam Rengasami Sender: "Media Gateway Control (megaco)" From: Selvam Rengasami Subject: Re: Comments on MEGACO protocol X-To: Stephen Terrill To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi Stephen, Q.2941.3 is scheduled to be approved on June 15, 2000 - the same day that H.248 is scheduled to be approved. June 15 is the one day where there will be succession of short SG meetings for those Study Groups that need to approve Recommendations. SG 11 will be approving Q.2941.3 along with other documents during that day. That same day, there will be a brief SG 16 meeting to approve H.248. I understand that some other SGs will also have short meetings that day as well. Therefore, I do not believe that there would be any problem in referencing Q.2941.3. Cheers, -Selvam Stephen Terrill on 03/16/2000 05:26:11 PM Please respond to Stephen Terrill To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Selvam Rengasami/Telcordia) Subject: Re: Comments on MEGACO protocol Hi, The reason that this suggestion was not followed in the first place was for reasons of the referencing rules. A determined document is not allowed to reference a not determined document (like an RFC reference and I-D). I am not sure of the timing of the SG-11 decision cf the SG-16 decision of H.248. If it allows for this, then it might be OK, otherwise other solutions should be sought. Selvam Rengasami wrote: > Folks, > > One correction to my previous e-mail. > > If we accept my proposal, then we should consider changing the reference from > Q.2941.1 to Q.2941.3 in C.8 > > Cheers, > > -Selvam > > Selvam Rengasami on 03/16/2000 09:41:23 AM > > Please respond to Selvam Rengasami > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: (bcc: Selvam Rengasami/Telcordia) > Subject: Re: Comments on MEGACO protocol > > Christian, John, > > I think the issue that Keith is raising is an interesting one. Q.2941.1 defines > a generic mechanism for transporting an identifier via the GIT in DSS2. As > Keith points out, in general, the GIT length is not limited by Q.2941.1, > therefore 4 or even 6 octets is not enough, if we want to support the generic > mechanism. > > Now, if we want to support the BNC-ID mechanism (e.g., for use in conjunction > with BICC), then Q.2941.3 defines how a BNC-ID is carried in the GIT. Q.2941.3 > constrains the GIT length for BNC-ID value to exactly four octets (no more, no > less). Specifically, Q.2941.3 gives the coding for Octet 5 (which identifies > BICC [Q.1901] and for Octet 6 indicates that the identifier is a BNC-ID. In > addition, Octet 6.1 (the length of the identifier) is required to be coded to a > value of 4. Finally octets 6.2 through 6.5 provide the four octet BNC-ID value. > > If we want to allow for future variations in Q.2941.3 or even Q.2941.1, then we > may want to consider allowing more than four octets for the BIR in C.8. > > I am basically interested in having the BNC-ID value (as defined by Q.2941.3) > signaled between the MGC and the MG. Four octets would suffice for this > purpose. I propose that we agree that the BIR for C.8 can only contain the > BNC-ID value as defined in Q.2941.3 (i.e., octets 6.2 through 6.5) which > requires no change to the document. > > By the way, Q.2941.3 (along with the other BICC related standards) is scheduled > to be approved (decided) in the Special meeting of SG 11 on June 15. > > Cheers, > > -Selvam Rengasami > > Telcordia Technologies > > Tel: +1 732 758 5260 > E-mail: srengasa@telcordia.com > > Christian Groves on 03/15/2000 06:58:59 PM > > Please respond to Christian Groves > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: (bcc: Selvam Rengasami/Telcordia) > Subject: Re: Comments on MEGACO protocol > > G'Day John, > > The property name is BIR. > > Perhaps the following change might work? > > BNCid 8000 6 OCTETS GIT (Generic Identifier Transport) > BNCid (Octet 5a and above) > Ref.: Recommendation Q.2941.1 (09/97) > > Cheers, Christian > > John Segers wrote: > > > > Christian, > > > > I believe it makes sense when it is used for binding reference. If we > > only use octet 5 and above, and only use the GIT parameter for this > > specific case, we should rethink the name of the parameter. Using GIT > > with a reference to Q.2941.1 will undoubtedly lead to confusion. > > > > John > > > > Christian Groves wrote: > > > > > > G'Day Keith and John, > > > > > > Regarding 6 the intention was to use this as a binding reference > > > (BNCid). Annex C should refer to octet 5 and above. For the BNCid the > > > length as per the GIT would be 6 octets. Make sense? > > > > > > Cheers, Christian > > > > > > John Segers wrote: > > > > > > > > Keith, > > > > > > > > Most of the changes you request are ok. There's a couple that I don't > > > > know about: > > > > - (Re. 3) I thought that references to ITU Rec. have to be specific > > > > (i.e., including a date). I asked Glen, and he's not sure either. > > > > We'll check. > > > > - (Re. 5) What headers are missing according to you? The current ASN.1 > > > > starts with "MEDIA-GATEWAY-CONTROL DEFINITIONS AUTOMATIC TAGS::=". I > > > > checked the syntax with the OSS tools and didn't find a problem. > > > > - (Re. 6) I believe this was brought in through MSF and I never > > > > checked. Having looked up Q.2941.1 now, I agree that 4 octets is > > > > restrictive. > > > > > > > > John > > > > > > > > "Drage, Keith" wrote: > > > > > > > > > > Attached please find a number of editorial comments on the Geneva output > > > > > document, which we also understand is identical to the MEGACO last call > > > > > document. These points are not intended to be controversial. In the > event > > > > > that discussion is required to resolve such a comment, then we will > withdraw > > > > > the comment in order to allow the document to proceed. > > > > > > > > > > 1) Abbreviations. "BRI" is never used and therefore should be > removed > > > > > from the list of abbreviations. > > > > > > > > > > 2) References. Q.724 is never used and should be removed. > > > > > > > > > > 3) References and annex C. Where a reference is only used in annex > C, > > > > > we believe in general in most cases these should be undated (i.e. the > latest > > > > > version of the referenced document applies). This in particular applies > to > > > > > Q.931, Q. 2931, Q.763 where ITU-T SG11 have no intention of changing > > > > > codepoints to different values, but do reserve the right to add new > values. > > > > > Surely the whole ethos of annex C is that new values do get > automatically > > > > > incorporated. > > > > > > > > > > 4) References (and annex C if comment 3 not accepted). Some of the > > > > > dates are incorrect. Q.761-4 have a date of December 1999 as that was > > > > > decided last year. Q.2931 should reflect the date of the latest > amendment > > > > > (4) which we believe is also December 1999. > > > > > > > > > > 5) Annex A. We could not find the module header, or an exports > > > > > statement, for the ASN.1. The module header is mandatory parts of the > ASN.1, > > > > > and gives that module an object identifier, which is needed for inport > to > > > > > anything else. > > > > > > > > > > 6) Annex C, C.8, generic identifier transport. We are not sure how > you > > > > > fit this into four octets. Is there some subset of the generic > identifier > > > > > transport information element that is being used? Various codings of > this > > > > > information element get very, very long. > > > > > > > > > > 7) Annex C, C.9, ITC has a reference to a note 2, which is not in > the > > > > > table. Is this a spurious inport from the referenced standard? If so, we > > > > > believe it can be deleted. > > > > > > > > > > 8) Annex C, C.9. References to Q.931 need to identify that the > > > > > references are to the encoding in the Bearer capability information > element, > > > > > and not to the Low layer information element. The latter has identical > > > > > fields with the same code values, but has a more extensive range of > values > > > > > assigned. This is because some values (particularly at layer 3) are only > > > > > defined for end user to addressed end user usage. I believe in H.248 > only > > > > > the more restricted list in the Bearer capability information element > would > > > > > be valid. > > > > > > > > > > Keith Drage > > > > > > > > > > > --------------------------------------------------------------- > > > > > > Keith Drage (keith.drage@siemenscomms.co.uk) > > > > > > Siemens Communications Limited, > > > > > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > > > > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > > > > > --------------------------------------------------------------- > > > > > > Internet communications are not secure and therefore Siemens > > > > > > Communications Limited does not accept legal responsibility for the > > > > > > contents of this message. Any views or opinions presented are solely > those > > > > > > of the author and do not necessarily represent those of Siemens > > > > > > Communications Limited unless otherwise specifically stated. > > > > > > > > > > > > > > > > > > > > -- > > > > John Segers email: jsegers@lucent.com > > > > Lucent Technologies Room HE 306 > > > > Dept. Forward Looking Work phone: +31 35 687 4724 > > > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > > > > -- > > John Segers email: jsegers@lucent.com > > Lucent Technologies Room HE 306 > > Dept. Forward Looking Work phone: +31 35 687 4724 > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 16 23:50:44 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18282 for ; Thu, 16 Mar 2000 23:50:44 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C9F7A560@standards.nortelnetworks.com>; Thu, 16 Mar 2000 23:46:03 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 92063 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 16 Mar 2000 23:44:55 -0500 Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3BA40ED0@standards.nortelnetworks.com>; Thu, 16 Mar 2000 23:34:54 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id FAA09417 for ; Fri, 17 Mar 2000 05:39:11 +0100 (MET) 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 FAA15115 for ; Fri, 17 Mar 2000 05:39:10 +0100 (MET) Received: from ericsson.com (mc2dh214.epa.ericsson.se [146.11.87.214]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id FAA11702 for ; Fri, 17 Mar 2000 05:39:08 +0100 (MET) X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: <4.2.2.20000313172117.00a66de0@dogwood.cisco.com> <38CE4D0F.A514434F@americasm01.nt.com> <38D1AA75.843C39D6@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38D1B6EC.CAC0CA3@ericsson.com> Date: Fri, 17 Mar 2000 15:39:08 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Descriptor processing order To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Abdallah, I can buy saying that descriptors are processed in order but what do we gain by adding "All commands are atomic operations, either succeed or fail as a whole". What does this really mean?? If one decriptor is executed and the next descriptor fails what does the MG do? Christian Flemming Andreasen wrote: > > Sounds good to me. > > -- Flemming > > Abdallah Rayhan wrote: > > > I believe there is an agreement that commands are atomic, either > > succeed or fail and no partial commands. but I agree with you that > > there is no text, up to my knowledge, saying that descriptors are > > attempted in order. The closest we get to this is in Section 8, > > "Transactions guarantee ordered Command processing. That is, Commands > > within a Transaction are executed sequentially. Ordering of Transactions is > > NOT guaranteed - transactions may be executed in any order, or > > simultaneously." > > > > I propose adding the following sentence to the above paragraph, > > " All commands are atomic operations, either succeed or fail as a whole, > > and descriptors within commands are processed in sequence of their > > order." > > > > Abdallah Rayhan > > > > Chip Sharp wrote: > > > > > Due to a previous question on event handling, I went through the output of > > > SG16 (TD37) looking for text on the ordering of processing of descriptors. > > > > > > However, I could find no text in the document that describes in what order > > > a MG or MGC should process descriptors. I was specifically wondering if > > > the TerminationStateDescriptor was processed before the > > > EventsDescriptor. This has implications in that the order of processing > > > the value of the EventBufferControl parameter in the > > > TerminationStateDescriptor and the EventsDescriptor will affect how events > > > in the EventBuffer are processed. > > > > > > If TerminationStateDescriptor is processed first and EventBufferControl=Off > > > (previous LockStep), then all events are discarded. If EventsDescriptor is > > > processed first then at least one more event will be reported before the > > > EventBuffer is flushed (ignoring the previous discussion as to whether this > > > is desirable or not). > > > > > > It seems there may be any number of conditions like this that will depend > > > on ordering of processing of descriptors in the command. > > > > > > Shouldn't there be some basic text in the spec that either specifies that > > > the receiver of a command should process the descriptors in the order > > > received or that the receiver can process them in any order desired? I > > > prefer the former. The latter seems a little indeterminate. > > > > > > If there is already text of this nature in the document, please educate me > > > as to its location. > > > > > > Thanks, > > > Chip > > > Support NetAid! http://www.netaid.org > > > -------------------------------------------------- > > > Chip Sharp Consulting Engineering > > > Cisco Systems Telco Bio-region > > > Reality - Love it or Leave it. > > > -------------------------------------------------- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 17 02:40:55 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10126 for ; Fri, 17 Mar 2000 02:40:55 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8D13F3C0@standards.nortelnetworks.com>; Fri, 17 Mar 2000 2:36:08 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 92122 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Mar 2000 02:35:02 -0500 Received: from hd2.dot.net.in (202.54.30.2) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FEFE5090@standards.nortelnetworks.com>; Fri, 17 Mar 2000 2:25:00 -0500 Received: from hyd.chiplogic.com ([203.197.20.184]) by hd2.dot.net.in (8.8.8/8.8.8) with ESMTP id MAA31756 for ; Fri, 17 Mar 2000 12:57:53 +0530 (IST) Received: from ramana ([192.168.2.62]) by hyd.chiplogic.com (8.8.7/8.8.7) with SMTP id MAA29439 for ; Fri, 17 Mar 2000 12:09:27 +0530 X-Sender: ramana@192.168.2.1 X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <3.0.6.32.20000317122255.00c9d940@192.168.2.1> Date: Fri, 17 Mar 2000 02:35:02 -0500 Reply-To: Ramana Yarlagadda Sender: "Media Gateway Control (megaco)" From: Ramana Yarlagadda Subject: streams To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi, all (Reffering Sec 7.1.6 from MEGACO protocol) Streams are created by specifying a new StreamID on one of the terminations in a Context. A stream is deleted by setting empty Local and Remote descriptors for the stream with ReserveGroup and ReserveValue in LocalControl set to "false" on all terminations in the context that previously supported that stream. Ref'ing to the same when the stream is created on a termination, How is it(strem) being used to support on other termination with in the context? can somebody throw more light on that -thanks in advance -ramana From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 17 07:03:26 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22652 for ; Fri, 17 Mar 2000 07:03:25 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3684AE80@standards.nortelnetworks.com>; Fri, 17 Mar 2000 6:58:35 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 92392 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Mar 2000 06:57:25 -0500 Received: from gorilla.mchh.siemens.de by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0D1C8DB0@standards.nortelnetworks.com>; Fri, 17 Mar 2000 6:57:25 -0500 Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id NAA18525 for ; Fri, 17 Mar 2000 13:00:48 +0100 (MET) Received: from mchh202e.demchh201e.icn.siemens.de ([218.1.68.105]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id NAA08563 for ; Fri, 17 Mar 2000 13:01:37 +0100 (MET) Received: by MCHH202E with Internet Mail Service (5.5.2448.0) id ; Fri, 17 Mar 2000 13:02:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <1BAFEBDF4429D311BA4C0008C70DB9D2809542@MCHH245E> Date: Fri, 17 Mar 2000 13:02:39 +0100 Reply-To: Ruppelt Christian Sender: "Media Gateway Control (megaco)" From: Ruppelt Christian Subject: "IP/IP" Media gateways? To: MEGACO@STANDARDS.NORTELNETWORKS.COM maybe I missed the discussion... Does H.248/Megaco provide a solution for "IP/IP" Media gateways? Motivation: IP Domain A IP Domain B MGC--(e.g. BICC)----MGC---------(e.g.BICC---MGC----------MGC / / / (H.248) (H.248 ???) (H.248 ???) \ \ \ MG--IP Network A---"IP/IP MG"---Public---"IP/IP MG"----IP NetB Internet IP real time streams cross borders between different administrative domains, (e.g.VoIP VPNs embedded in Telco IP backbones,enterprise intranets) The address of MG in Domain A is not known in the Domain B and vice versa. A solution for IPv4 and it's restricted address space is required. For a Call from Domain A into Domain B on a per call basis the MGC has to select the ports on the "IP/IP MG" Christian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 17 08:11:17 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17964 for ; Fri, 17 Mar 2000 08:11:16 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B7D721D0@standards.nortelnetworks.com>; Fri, 17 Mar 2000 8:06:37 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 92421 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Mar 2000 08:05:15 -0500 Received: from auemlsrv.firewall.lucent.com (192.11.223.161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.86D0C730@standards.nortelnetworks.com>; Fri, 17 Mar 2000 8:05:15 -0500 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 IAA20488 for ; Fri, 17 Mar 2000 08:09:33 -0500 (EST) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id IAA20475 for ; Fri, 17 Mar 2000 08:09:32 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA16078; Fri, 17 Mar 2000 14:09:28 +0100 (MET) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id OAA16074; Fri, 17 Mar 2000 14:09:28 +0100 (MET) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <1BAFEBDF4429D311BA4C0008C70DB9D2809542@MCHH245E> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38D22E7E.98C229F1@lucent.com> Date: Fri, 17 Mar 2000 14:09:18 +0100 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: "IP/IP" Media gateways? To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Christian, The box you labeled "IP/IP MG" is, according to your description a NAT device. I believe that ETSI TIPHON has started requirements work on controlling NATs in the media path of calls. Maybe megaco can meet the requirements for this IP/IP GW application. Cheers, John Ruppelt Christian wrote: > > maybe I missed the discussion... > > Does H.248/Megaco provide a solution for "IP/IP" Media gateways? > > Motivation: > > IP Domain A IP Domain B > MGC--(e.g. BICC)----MGC---------(e.g.BICC---MGC----------MGC > / / / > > (H.248) (H.248 ???) (H.248 ???) > \ \ \ > MG--IP Network A---"IP/IP MG"---Public---"IP/IP MG"----IP NetB > Internet > > IP real time streams cross borders between different administrative > domains, (e.g.VoIP VPNs embedded in Telco IP backbones,enterprise > intranets) > The address of MG in Domain A is not known in the Domain B and > vice versa. > A solution for IPv4 and it's restricted address space is required. > > For a Call from Domain A into Domain B on a per call basis the MGC > has to select the ports on the "IP/IP MG" > > Christian -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 17 08:49:56 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03404 for ; Fri, 17 Mar 2000 08:49:54 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.153E5190@standards.nortelnetworks.com>; Fri, 17 Mar 2000 8:45:01 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 92652 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Mar 2000 08:43:28 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DD8814C0@standards.nortelnetworks.com>; Fri, 17 Mar 2000 8:43:28 -0500 Received: from chsharp-tecra.cisco.com (chsharp-isdn.cisco.com [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id FAA23920; Fri, 17 Mar 2000 05:47:40 -0800 (PST) X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 References: <4.2.2.20000313172117.00a66de0@dogwood.cisco.com> <38CE4D0F.A514434F@americasm01.nt.com> <38D1AA75.843C39D6@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.1.2.20000317081943.00b80940@dogwood.cisco.com> Date: Fri, 17 Mar 2000 08:26:34 -0800 Reply-To: Chip Sharp Sender: "Media Gateway Control (megaco)" From: Chip Sharp Subject: Re: Descriptor processing order X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <38D1B6EC.CAC0CA3@ericsson.com> I'll leave it up to the experts, but I imagine it would be similar to a Q.931 SETUP message. If the switch executes one Information Element and the next one fails, the switch treats the entire SETUP message as in error. I believe there should be atomicity at some level. If we go one level deeper, we could look at what happens within a descriptor in the ordering of parameters. If one parameter succeeds and the next fails, the MG has to recover. I tend to think that a command should be atomic. It either succeeds or fails. I think independence of execution of descriptors would make it even more difficult than it already is for the MGC and MG to remain in synch (and sane). Chip At 03:39 PM 3/17/00 +1100, Christian Groves wrote: >G'Day Abdallah, > >I can buy saying that descriptors are processed in order but what do we >gain by adding "All commands are atomic operations, either succeed or >fail as a whole". What does this really mean?? >If one decriptor is executed and the next descriptor fails what does the >MG do? > >Christian > >Flemming Andreasen wrote: > > > > Sounds good to me. > > > > -- Flemming > > > > Abdallah Rayhan wrote: > > > > > I believe there is an agreement that commands are atomic, either > > > succeed or fail and no partial commands. but I agree with you that > > > there is no text, up to my knowledge, saying that descriptors are > > > attempted in order. The closest we get to this is in Section 8, > > > "Transactions guarantee ordered Command processing. That is, Commands > > > within a Transaction are executed sequentially. Ordering of > Transactions is > > > NOT guaranteed - transactions may be executed in any order, or > > > simultaneously." > > > > > > I propose adding the following sentence to the above paragraph, > > > " All commands are atomic operations, either succeed or fail as a whole, > > > and descriptors within commands are processed in sequence of their > > > order." > > > > > > Abdallah Rayhan > > > > > > Chip Sharp wrote: > > > > > > > Due to a previous question on event handling, I went through the > output of > > > > SG16 (TD37) looking for text on the ordering of processing of > descriptors. > > > > > > > > However, I could find no text in the document that describes in > what order > > > > a MG or MGC should process descriptors. I was specifically > wondering if > > > > the TerminationStateDescriptor was processed before the > > > > EventsDescriptor. This has implications in that the order of > processing > > > > the value of the EventBufferControl parameter in the > > > > TerminationStateDescriptor and the EventsDescriptor will affect how > events > > > > in the EventBuffer are processed. > > > > > > > > If TerminationStateDescriptor is processed first and > EventBufferControl=Off > > > > (previous LockStep), then all events are discarded. If > EventsDescriptor is > > > > processed first then at least one more event will be reported > before the > > > > EventBuffer is flushed (ignoring the previous discussion as to > whether this > > > > is desirable or not). > > > > > > > > It seems there may be any number of conditions like this that will > depend > > > > on ordering of processing of descriptors in the command. > > > > > > > > Shouldn't there be some basic text in the spec that either > specifies that > > > > the receiver of a command should process the descriptors in the order > > > > received or that the receiver can process them in any order desired? I > > > > prefer the former. The latter seems a little indeterminate. > > > > > > > > If there is already text of this nature in the document, please > educate me > > > > as to its location. > > > > > > > > Thanks, > > > > Chip > > > > Support NetAid! http://www.netaid.org > > > > -------------------------------------------------- > > > > Chip Sharp Consulting Engineering > > > > Cisco Systems Telco Bio-region > > > > Reality - Love it or Leave it. > > > > -------------------------------------------------- Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. -------------------------------------------------- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 17 10:03:15 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01245 for ; Fri, 17 Mar 2000 10:03:14 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4AE37D20@standards.nortelnetworks.com>; Fri, 17 Mar 2000 9:58:06 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 92708 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Mar 2000 09:57:06 -0500 Received: from aztek-eng.com (206.168.36.88) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.26ADC640@standards.nortelnetworks.com>; Fri, 17 Mar 2000 9:57:05 -0500 Received: from aztek-eng.com (jfpc [191.0.6.28]) by aztek-eng.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09956 for ; Fri, 17 Mar 2000 08:01:15 -0700 (MST) X-Mailer: Mozilla 4.51 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38D248B9.CA3F8D92@aztek-eng.com> Date: Fri, 17 Mar 2000 08:01:13 -0700 Reply-To: Jo Friedman Sender: "Media Gateway Control (megaco)" From: Jo Friedman Organization: Aztek Engineering Subject: ABNF for alternativeValue To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit In the MEGACO text-encoding production alternativeValue = ( VALUE / LSBRKT VALUE *(COMMA VALUE) RSBRKT / LSBRKT VALUE DOT DOT VALUE RSBRKT ) The following is a legal VALUE 1..2 because a VALUE can contain dots (the final SafeChar is '.'). So unfortunately, there are two ways to parse [1..2] it could be one VALUE (the first required VALUE) in LSBRKT VALUE *(COMMA VALUE) RSBRKT or it could be two values separated by two dots as in LSBRKT VALUE DOT DOT VALUE RSBRKT Any thoughts on how to resolve this? Jo From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 17 10:08:11 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03105 for ; Fri, 17 Mar 2000 10:08:09 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.92F902B0@standards.nortelnetworks.com>; Fri, 17 Mar 2000 10:00:07 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 92717 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Mar 2000 09:58:58 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.699352E0@standards.nortelnetworks.com>; Fri, 17 Mar 2000 9:58:58 -0500 Received: from chsharp-tecra.cisco.com (chsharp-isdn.cisco.com [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id GAA04673; Fri, 17 Mar 2000 06:55:55 -0800 (PST) X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.1.2.20000317093345.00b206f0@dogwood.cisco.com> Date: Fri, 17 Mar 2000 09:55:23 -0800 Reply-To: Chip Sharp Sender: "Media Gateway Control (megaco)" From: Chip Sharp Subject: Re: "IP/IP" Media gateways? X-To: Ruppelt Christian To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <1BAFEBDF4429D311BA4C0008C70DB9D2809542@MCHH245E> H.248 is pretty flexible, so I suppose you could define a package to do about anything you want. Whether it makes sense or not is another matter. IMO, the network architecture you show below (and which I have seen before in BICC discussions) probably has a lot bigger problems than just the H.248 part. But that isn't BICC's problem I guess. Yes, there has been discussions of H.248 controlling what you refer to as IP-IP gateway devices (e.g., IVRs, transcoders, etc.) and I can envision a simple first cut at a package to do this. I'm actually not sure any new work would need to be done. As John has mentioned, this looks like a NAT function. You don't give much info on what the gateway would have to do so I'm guessing here. Using H.248, the first MGC in Net A would have to give the first MG in Net A the IP address of the IP-IP MG as the destination of the RTP stream. The MGC controlling the IP-IP MG would have to set up a context with 2 packet terminations. One termination has an IP address of an interface on Net A and the other termination has an IP address of an interface on the Public Internet. The same action would have to occur between the other MGC and IP-IP MG. The MG would then "just" have to translate the the IP addresses between terminations. If the port number needs to be translated, then that could probably be handled as well. The MGC controlling the IP-IP MGs would act like a mediation device between the two domains in terms of translating the signaling. Now how you set up your IGP and BGP to handle routing within your network and between networks is a different matter, especially if you are planning to support any other applications on your nets other than VoIP. Chip At 01:02 PM 3/17/00 +0100, Ruppelt Christian wrote: >maybe I missed the discussion... > >Does H.248/Megaco provide a solution for "IP/IP" Media gateways? > > >Motivation: IP Domain A IP Domain B MGC--(BICC)----MGC--(BICC)---MGC------ / / / (H.248) (H.248 ???) (H.248 ???) \ \ \ MG--Net A---"IP/IP MG"----"IP/IP MG"--NetB ^ Public Internet >IP real time streams cross borders between different administrative >domains, (e.g.VoIP VPNs embedded in Telco IP backbones,enterprise >intranets). The address of MG in Domain A is not known in the Domain B and >vice versa. A solution for IPv4 and it's restricted address space is >required. > >For a Call from Domain A into Domain B on a per call basis the MGC >has to select the ports on the "IP/IP MG" > >Christian Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. -------------------------------------------------- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 17 10:08:13 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03136 for ; Fri, 17 Mar 2000 10:08:11 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DC4BC330@standards.nortelnetworks.com>; Fri, 17 Mar 2000 10:02:10 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 92749 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Mar 2000 10:01:49 -0500 Received: from ns-inetext.inet.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CFDF3870@standards.nortelnetworks.com>; Fri, 17 Mar 2000 10:01:49 -0500 Received: from harpo.inetint.com (harpo [172.16.99.60]) by ns-inetext.inet.com (8.9.2/8.9.2) with ESMTP id JAA10669 for ; Fri, 17 Mar 2000 09:04:52 -0600 (CST) Received: from inet.com ([172.16.63.49]) by harpo.inetint.com (Netscape Messaging Server 3.6) with ESMTP id AAA5DEC; Fri, 17 Mar 2000 09:10:27 -0600 X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <852568A4.0050AE6C.00@notes950.cc.telcordia.com> <38D15F82.5C3BBF29@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38D249A1.C524FEE7@inet.com> Date: Fri, 17 Mar 2000 09:05:05 -0600 Reply-To: Mart Nurmet Sender: "Media Gateway Control (megaco)" From: Mart Nurmet Organization: Inet - Product Line Management Subject: Re: Comments on MEGACO protocol X-To: Stephen Terrill To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Stephen: If and when Q.2941.3 (along with the other BICC related standards) are approved at the Special meeting of SG 11 on June 15 can the reference be changed? Or should we wait till that happens? Stephen Terrill wrote: > Hi, > > The reason that this suggestion was not followed in the first place was for reasons of the referencing rules. A determined document is not allowed to reference a not determined document (like an RFC reference and I-D). I am not sure of the timing of the SG-11 decision cf the SG-16 decision of H.248. If it allows for this, then it might be OK, otherwise other solutions should be sought. > > Selvam Rengasami wrote: > > > Folks, > > > > One correction to my previous e-mail. > > > > If we accept my proposal, then we should consider changing the reference from > > Q.2941.1 to Q.2941.3 in C.8 > > > > Cheers, > > > > -Selvam > > > > Selvam Rengasami on 03/16/2000 09:41:23 AM > > > > Please respond to Selvam Rengasami > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > cc: (bcc: Selvam Rengasami/Telcordia) > > Subject: Re: Comments on MEGACO protocol > > > > Christian, John, > > > > I think the issue that Keith is raising is an interesting one. Q.2941.1 defines > > a generic mechanism for transporting an identifier via the GIT in DSS2. As > > Keith points out, in general, the GIT length is not limited by Q.2941.1, > > therefore 4 or even 6 octets is not enough, if we want to support the generic > > mechanism. > > > > Now, if we want to support the BNC-ID mechanism (e.g., for use in conjunction > > with BICC), then Q.2941.3 defines how a BNC-ID is carried in the GIT. Q.2941.3 > > constrains the GIT length for BNC-ID value to exactly four octets (no more, no > > less). Specifically, Q.2941.3 gives the coding for Octet 5 (which identifies > > BICC [Q.1901] and for Octet 6 indicates that the identifier is a BNC-ID. In > > addition, Octet 6.1 (the length of the identifier) is required to be coded to a > > value of 4. Finally octets 6.2 through 6.5 provide the four octet BNC-ID value. > > > > If we want to allow for future variations in Q.2941.3 or even Q.2941.1, then we > > may want to consider allowing more than four octets for the BIR in C.8. > > > > I am basically interested in having the BNC-ID value (as defined by Q.2941.3) > > signaled between the MGC and the MG. Four octets would suffice for this > > purpose. I propose that we agree that the BIR for C.8 can only contain the > > BNC-ID value as defined in Q.2941.3 (i.e., octets 6.2 through 6.5) which > > requires no change to the document. > > > > By the way, Q.2941.3 (along with the other BICC related standards) is scheduled > > to be approved (decided) in the Special meeting of SG 11 on June 15. > > > > Cheers, > > > > -Selvam Rengasami > > > > Telcordia Technologies > > > > Tel: +1 732 758 5260 > > E-mail: srengasa@telcordia.com > > > > Christian Groves on 03/15/2000 06:58:59 PM > > > > Please respond to Christian Groves > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > cc: (bcc: Selvam Rengasami/Telcordia) > > Subject: Re: Comments on MEGACO protocol > > > > G'Day John, > > > > The property name is BIR. > > > > Perhaps the following change might work? > > > > BNCid 8000 6 OCTETS GIT (Generic Identifier Transport) > > BNCid (Octet 5a and above) > > Ref.: Recommendation Q.2941.1 (09/97) > > > > Cheers, Christian > > > > John Segers wrote: > > > > > > Christian, > > > > > > I believe it makes sense when it is used for binding reference. If we > > > only use octet 5 and above, and only use the GIT parameter for this > > > specific case, we should rethink the name of the parameter. Using GIT > > > with a reference to Q.2941.1 will undoubtedly lead to confusion. > > > > > > John > > > > > > Christian Groves wrote: > > > > > > > > G'Day Keith and John, > > > > > > > > Regarding 6 the intention was to use this as a binding reference > > > > (BNCid). Annex C should refer to octet 5 and above. For the BNCid the > > > > length as per the GIT would be 6 octets. Make sense? > > > > > > > > Cheers, Christian > > > > > > > > John Segers wrote: > > > > > > > > > > Keith, > > > > > > > > > > Most of the changes you request are ok. There's a couple that I don't > > > > > know about: > > > > > - (Re. 3) I thought that references to ITU Rec. have to be specific > > > > > (i.e., including a date). I asked Glen, and he's not sure either. > > > > > We'll check. > > > > > - (Re. 5) What headers are missing according to you? The current ASN.1 > > > > > starts with "MEDIA-GATEWAY-CONTROL DEFINITIONS AUTOMATIC TAGS::=". I > > > > > checked the syntax with the OSS tools and didn't find a problem. > > > > > - (Re. 6) I believe this was brought in through MSF and I never > > > > > checked. Having looked up Q.2941.1 now, I agree that 4 octets is > > > > > restrictive. > > > > > > > > > > John > > > > > > > > > > "Drage, Keith" wrote: > > > > > > > > > > > > Attached please find a number of editorial comments on the Geneva output > > > > > > document, which we also understand is identical to the MEGACO last call > > > > > > document. These points are not intended to be controversial. In the > > event > > > > > > that discussion is required to resolve such a comment, then we will > > withdraw > > > > > > the comment in order to allow the document to proceed. > > > > > > > > > > > > 1) Abbreviations. "BRI" is never used and therefore should be > > removed > > > > > > from the list of abbreviations. > > > > > > > > > > > > 2) References. Q.724 is never used and should be removed. > > > > > > > > > > > > 3) References and annex C. Where a reference is only used in annex > > C, > > > > > > we believe in general in most cases these should be undated (i.e. the > > latest > > > > > > version of the referenced document applies). This in particular applies > > to > > > > > > Q.931, Q. 2931, Q.763 where ITU-T SG11 have no intention of changing > > > > > > codepoints to different values, but do reserve the right to add new > > values. > > > > > > Surely the whole ethos of annex C is that new values do get > > automatically > > > > > > incorporated. > > > > > > > > > > > > 4) References (and annex C if comment 3 not accepted). Some of the > > > > > > dates are incorrect. Q.761-4 have a date of December 1999 as that was > > > > > > decided last year. Q.2931 should reflect the date of the latest > > amendment > > > > > > (4) which we believe is also December 1999. > > > > > > > > > > > > 5) Annex A. We could not find the module header, or an exports > > > > > > statement, for the ASN.1. The module header is mandatory parts of the > > ASN.1, > > > > > > and gives that module an object identifier, which is needed for inport > > to > > > > > > anything else. > > > > > > > > > > > > 6) Annex C, C.8, generic identifier transport. We are not sure how > > you > > > > > > fit this into four octets. Is there some subset of the generic > > identifier > > > > > > transport information element that is being used? Various codings of > > this > > > > > > information element get very, very long. > > > > > > > > > > > > 7) Annex C, C.9, ITC has a reference to a note 2, which is not in > > the > > > > > > table. Is this a spurious inport from the referenced standard? If so, we > > > > > > believe it can be deleted. > > > > > > > > > > > > 8) Annex C, C.9. References to Q.931 need to identify that the > > > > > > references are to the encoding in the Bearer capability information > > element, > > > > > > and not to the Low layer information element. The latter has identical > > > > > > fields with the same code values, but has a more extensive range of > > values > > > > > > assigned. This is because some values (particularly at layer 3) are only > > > > > > defined for end user to addressed end user usage. I believe in H.248 > > only > > > > > > the more restricted list in the Bearer capability information element > > would > > > > > > be valid. > > > > > > > > > > > > Keith Drage > > > > > > > > > > > > > --------------------------------------------------------------- > > > > > > > Keith Drage (keith.drage@siemenscomms.co.uk) > > > > > > > Siemens Communications Limited, > > > > > > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > > > > > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > > > > > > --------------------------------------------------------------- > > > > > > > Internet communications are not secure and therefore Siemens > > > > > > > Communications Limited does not accept legal responsibility for the > > > > > > > contents of this message. Any views or opinions presented are solely > > those > > > > > > > of the author and do not necessarily represent those of Siemens > > > > > > > Communications Limited unless otherwise specifically stated. > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > John Segers email: jsegers@lucent.com > > > > > Lucent Technologies Room HE 306 > > > > > Dept. Forward Looking Work phone: +31 35 687 4724 > > > > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > > > > > > -- > > > John Segers email: jsegers@lucent.com > > > Lucent Technologies Room HE 306 > > > Dept. Forward Looking Work phone: +31 35 687 4724 > > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 17 11:20:10 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02891 for ; Fri, 17 Mar 2000 11:20:10 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.173D7060@standards.nortelnetworks.com>; Fri, 17 Mar 2000 11:15:24 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 92927 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Mar 2000 11:14:20 -0500 Received: from gorilla.mchh.siemens.de by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F1320F20@standards.nortelnetworks.com>; Fri, 17 Mar 2000 11:14:20 -0500 Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA02887 for ; Fri, 17 Mar 2000 17:17:41 +0100 (MET) Received: from mchh202e.demchh201e.icn.siemens.de ([218.1.68.105]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA08812 for ; Fri, 17 Mar 2000 17:18:29 +0100 (MET) Received: by MCHH202E with Internet Mail Service (5.5.2448.0) id ; Fri, 17 Mar 2000 17:19:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <1BAFEBDF4429D311BA4C0008C70DB9D2809544@MCHH245E> Date: Fri, 17 Mar 2000 17:19:32 +0100 Reply-To: Ruppelt Christian Sender: "Media Gateway Control (megaco)" From: Ruppelt Christian Subject: AW: "IP/IP" Media gateways? To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA02891 I apologize for the litte info but your guessing meets my thinking VoIP call from Network A to B. The MGC at the Border (network A/Internet) creates a context in the "IP/IP MG". This context contains two terminations for the packet side. One for the "On-net-side" (Network A) and one for the "Off-net-side" (Network B). I think with the current H.248 it is not possible to address two packet terminations in a MG and each one of them in a different IP-network, right? Christian > -----Ursprüngliche Nachricht----- > Von: Chip Sharp [SMTP:chsharp@cisco.com] > Gesendet am: Freitag, 17. März 2000 18:55 > An: Ruppelt Christian; MEGACO@STANDARDS.NORTELNETWORKS.COM > Betreff: Re: "IP/IP" Media gateways? > > H.248 is pretty flexible, so I suppose you could define a package to do > about anything you want. Whether it makes sense or not is another matter. > > IMO, the network architecture you show below (and which I have seen before > > in BICC discussions) probably has a lot bigger problems than just the > H.248 > part. But that isn't BICC's problem I guess. > > Yes, there has been discussions of H.248 controlling what you refer to as > IP-IP gateway devices (e.g., IVRs, transcoders, etc.) and I can envision a > > simple first cut at a package to do this. I'm actually not sure any new > work would need to be done. > > As John has mentioned, this looks like a NAT function. You don't give > much > info on what the gateway would have to do so I'm guessing here. > > Using H.248, the first MGC in Net A would have to give the first MG in Net > > A the IP address of the IP-IP MG as the destination of the RTP stream. > The > MGC controlling the IP-IP MG would have to set up a context with 2 packet > terminations. One termination has an IP address of an interface on Net A > and the other termination has an IP address of an interface on the Public > Internet. The same action would have to occur between the other MGC and > IP-IP MG. The MG would then "just" have to translate the the IP addresses > > between terminations. If the port number needs to be translated, then > that > could probably be handled as well. The MGC controlling the IP-IP MGs > would > act like a mediation device between the two domains in terms of > translating > the signaling. > > Now how you set up your IGP and BGP to handle routing within your network > and between networks is a different matter, especially if you are planning > > to support any other applications on your nets other than VoIP. > > Chip > > At 01:02 PM 3/17/00 +0100, Ruppelt Christian wrote: > >maybe I missed the discussion... > > > >Does H.248/Megaco provide a solution for "IP/IP" Media gateways? > > > > > >Motivation: > > IP Domain A IP Domain B > MGC--(BICC)----MGC--(BICC)---MGC------ > / / / > (H.248) (H.248 ???) (H.248 ???) > \ \ \ > MG--Net A---"IP/IP MG"----"IP/IP MG"--NetB > ^ > Public > Internet > > >IP real time streams cross borders between different administrative > >domains, (e.g.VoIP VPNs embedded in Telco IP backbones,enterprise > >intranets). The address of MG in Domain A is not known in the Domain B > and > >vice versa. A solution for IPv4 and it's restricted address space is > >required. > > > >For a Call from Domain A into Domain B on a per call basis the MGC > >has to select the ports on the "IP/IP MG" > > > >Christian > > Support NetAid! http://www.netaid.org > -------------------------------------------------- > Chip Sharp Consulting Engineering > Cisco Systems Telco Bio-region > Reality - Love it or Leave it. > -------------------------------------------------- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 17 12:27:15 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00836 for ; Fri, 17 Mar 2000 12:27:14 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.76E9FF70@standards.nortelnetworks.com>; Fri, 17 Mar 2000 12:22:30 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 93007 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Mar 2000 12:21:02 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.42501DD0@standards.nortelnetworks.com>; Fri, 17 Mar 2000 12:21:02 -0500 Received: from chsharp-tecra.cisco.com (chsharp-isdn.cisco.com [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id JAA19026; Fri, 17 Mar 2000 09:17:57 -0800 (PST) X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Message-ID: <4.3.1.2.20000317120331.00b593b0@dogwood.cisco.com> Date: Fri, 17 Mar 2000 12:13:07 -0800 Reply-To: Chip Sharp Sender: "Media Gateway Control (megaco)" From: Chip Sharp Subject: Re: AW: "IP/IP" Media gateways? X-To: Ruppelt Christian To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <1BAFEBDF4429D311BA4C0008C70DB9D2809544@MCHH245E> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA00836 At 05:19 PM 3/17/00 +0100, Ruppelt Christian wrote: >I apologize for the litte info >but your guessing meets my thinking > >VoIP call from Network A to B. >The MGC at the Border (network A/Internet) creates a context in the "IP/IP >MG". >This context contains two terminations for the packet side. >One for the "On-net-side" (Network A) and one for the "Off-net-side" >(Network B). >I think with the current H.248 it is not possible to address >two packet terminations in a MG and each one of them in a different >IP-network, >right? No, I think H.248 can handle this pretty easily. As I said, it is very flexible. Worst case, it would require a new package. Anyone up for defining a NAT package. ;-) Please note that just because I think it can be done fairly easily in H.248 does not means that I think it makes sense to do it. Of course, you guys may have already figured out all the routing and other implications. >Christian > > > -----Ursprüngliche Nachricht----- > > Von: Chip Sharp [SMTP:chsharp@cisco.com] > > Gesendet am: Freitag, 17. März 2000 18:55 > > An: Ruppelt Christian; MEGACO@STANDARDS.NORTELNETWORKS.COM > > Betreff: Re: "IP/IP" Media gateways? > > > > H.248 is pretty flexible, so I suppose you could define a package to do > > about anything you want. Whether it makes sense or not is another matter. > > > > IMO, the network architecture you show below (and which I have seen before > > > > in BICC discussions) probably has a lot bigger problems than just the > > H.248 > > part. But that isn't BICC's problem I guess. > > > > Yes, there has been discussions of H.248 controlling what you refer to as > > IP-IP gateway devices (e.g., IVRs, transcoders, etc.) and I can envision a > > > > simple first cut at a package to do this. I'm actually not sure any new > > work would need to be done. > > > > As John has mentioned, this looks like a NAT function. You don't give > > much > > info on what the gateway would have to do so I'm guessing here. > > > > Using H.248, the first MGC in Net A would have to give the first MG in Net > > > > A the IP address of the IP-IP MG as the destination of the RTP stream. > > The > > MGC controlling the IP-IP MG would have to set up a context with 2 packet > > terminations. One termination has an IP address of an interface on Net A > > and the other termination has an IP address of an interface on the Public > > Internet. The same action would have to occur between the other MGC and > > IP-IP MG. The MG would then "just" have to translate the the IP addresses > > > > between terminations. If the port number needs to be translated, then > > that > > could probably be handled as well. The MGC controlling the IP-IP MGs > > would > > act like a mediation device between the two domains in terms of > > translating > > the signaling. > > > > Now how you set up your IGP and BGP to handle routing within your network > > and between networks is a different matter, especially if you are planning > > > > to support any other applications on your nets other than VoIP. > > > > Chip > > > > At 01:02 PM 3/17/00 +0100, Ruppelt Christian wrote: > > >maybe I missed the discussion... > > > > > >Does H.248/Megaco provide a solution for "IP/IP" Media gateways? > > > > > > > > >Motivation: > > > > IP Domain A IP Domain B > > MGC--(BICC)----MGC--(BICC)---MGC------ > > / / / > > (H.248) (H.248 ???) (H.248 ???) > > \ \ \ > > MG--Net A---"IP/IP MG"----"IP/IP MG"--NetB > > ^ > > Public > > Internet > > > > >IP real time streams cross borders between different administrative > > >domains, (e.g.VoIP VPNs embedded in Telco IP backbones,enterprise > > >intranets). The address of MG in Domain A is not known in the Domain B > > and > > >vice versa. A solution for IPv4 and it's restricted address space is > > >required. > > > > > >For a Call from Domain A into Domain B on a per call basis the MGC > > >has to select the ports on the "IP/IP MG" > > > > > >Christian > > > > Support NetAid! http://www.netaid.org > > -------------------------------------------------- > > Chip Sharp Consulting Engineering > > Cisco Systems Telco Bio-region > > Reality - Love it or Leave it. > > -------------------------------------------------- Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. -------------------------------------------------- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 17 17:27:48 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03673 for ; Fri, 17 Mar 2000 17:27:48 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7502FDE0@standards.nortelnetworks.com>; Fri, 17 Mar 2000 17:23:06 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 93449 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Mar 2000 17:21:36 -0500 Received: from mel.alcatel.fr (212.208.74.132) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3F5BCAF0@standards.nortelnetworks.com>; Fri, 17 Mar 2000 17:21:36 -0500 Received: from aifhs10.alcatel.fr (mailhub2.alcatel.fr [155.132.188.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id XAA22377; Fri, 17 Mar 2000 23:17:10 +0100 Received: from frmta01.netfr.alcatel.fr (frmta01.netfr.alcatel.fr [155.132.210.164]) by aifhs10.alcatel.fr (ALCANET/SMTP2) with SMTP id XAA29851; Fri, 17 Mar 2000 23:18:50 +0100 (MET) Received: by frmta01.netfr.alcatel.fr(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id C12568A5.007B3129 ; Fri, 17 Mar 2000 23:25:35 +0100 X-Lotus-FromDomain: ALCATEL Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=0QdXVYpTQpSjCKy2pU4mfVnGOpVBzUb83wbnjl2hB9z5um4TiffcJPgt" Content-Disposition: inline Message-ID: Date: Fri, 17 Mar 2000 23:25:26 +0100 Reply-To: Ameneh.Zahir-Emami@ALCATEL.FR Sender: "Media Gateway Control (megaco)" From: Ameneh.Zahir-Emami@ALCATEL.FR Subject: Re: AW: "IP/IP" Media gateways? X-To: Chip Sharp To: MEGACO@STANDARDS.NORTELNETWORKS.COM --0__=0QdXVYpTQpSjCKy2pU4mfVnGOpVBzUb83wbnjl2hB9z5um4TiffcJPgt Content-type: text/plain; charset=us-ascii Content-Disposition: inline Actually I think it make a lot of sense having H248 driving an IP / IP MG. VO-ADSL would be in my opinion one application and UMTS (mobile 3rd generation) would a second one. For UMTS (circuit part) it would mean for example an MG that is AAL2/AAL2 and switching of AAL2 could be driven by the MGC which receives the mobile call information. An H248 that drives an MG which is IP/IP would be useful for statistics (billing) puposes and IVRs as Christian and/or Chip said. Although this was not the original purpose of H248 since H248 aimed at driving a decomposed gateway that by definition was at a frontier of a circuit switched network and a packet network I believe that a package for a IP/IP MG would be a welcome generalisation of the H248 concept.. Ameneh Chip Sharp on 17/03/2000 21:13:07 Please respond to Chip Sharp To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Ameneh ZAHIR-EMAMI/FR/ALCATEL) Subject: Re: AW: "IP/IP" Media gateways? --0__=0QdXVYpTQpSjCKy2pU4mfVnGOpVBzUb83wbnjl2hB9z5um4TiffcJPgt Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable At 05:19 PM 3/17/00 +0100, Ruppelt Christian wrote: >I apologize for the litte info >but your guessing meets my thinking > >VoIP call from Network A to B. >The MGC at the Border (network A/Internet) creates a context in the "I= P/IP >MG". >This context contains two terminations for the packet side. >One for the "On-net-side" (Network A) and one for the "Off-net-side"= >(Network B). >I think with the current H.248 it is not possible to address >two packet terminations in a MG and each one of them in a different >IP-network, >right? No, I think H.248 can handle this pretty easily. As I said, it is very= flexible. Worst case, it would require a new package. Anyone up for defining a NAT package. ;-) Please note that just because I think it can be done fairly easily in H= .248 does not means that I think it makes sense to do it. Of course, you gu= ys may have already figured out all the routing and other implications. >Christian > > > -----Urspr=FCngliche Nachricht----- > > Von: Chip Sharp [SMTP:chsharp@cisco.com] > > Gesendet am: Freitag, 17. M=E4rz 2000 18:55 > > An: Ruppelt Christian; MEGACO@STANDARDS.NORTELNETWORKS.COM > > Betreff: Re: "IP/IP" Media gateways? > > > > H.248 is pretty flexible, so I suppose you could define a package t= o do > > about anything you want. Whether it makes sense or not is another = matter. > > > > IMO, the network architecture you show below (and which I have seen= before > > > > in BICC discussions) probably has a lot bigger problems than just t= he > > H.248 > > part. But that isn't BICC's problem I guess. > > > > Yes, there has been discussions of H.248 controlling what you refer= to as > > IP-IP gateway devices (e.g., IVRs, transcoders, etc.) and I can env= ision a > > > > simple first cut at a package to do this. I'm actually not sure an= y new > > work would need to be done. > > > > As John has mentioned, this looks like a NAT function. You don't g= ive > > much > > info on what the gateway would have to do so I'm guessing here. > > > > Using H.248, the first MGC in Net A would have to give the first MG= in Net > > > > A the IP address of the IP-IP MG as the destination of the RTP stre= am. > > The > > MGC controlling the IP-IP MG would have to set up a context with 2 = packet > > terminations. One termination has an IP address of an interface on= Net A > > and the other termination has an IP address of an interface on the = Public > > Internet. The same action would have to occur between the other MG= C and > > IP-IP MG. The MG would then "just" have to translate the the IP ad= dresses > > > > between terminations. If the port number needs to be translated, t= hen > > that > > could probably be handled as well. The MGC controlling the IP-IP M= Gs > > would > > act like a mediation device between the two domains in terms of > > translating > > the signaling. > > > > Now how you set up your IGP and BGP to handle routing within your n= etwork > > and between networks is a different matter, especially if you are p= lanning > > > > to support any other applications on your nets other than VoIP. > > > > Chip > > > > At 01:02 PM 3/17/00 +0100, Ruppelt Christian wrote: > > >maybe I missed the discussion... > > > > > >Does H.248/Megaco provide a solution for "IP/IP" Media gateways? > > > > > > > > >Motivation: > > > > IP Domain A IP Domain B > > MGC--(BICC)----MGC--(BICC)---MGC------ > > / / / > > (H.248) (H.248 ???) (H.248 ???) > > \ \ \ > > MG--Net A---"IP/IP MG"----"IP/IP MG"--NetB > > ^ > > Public > > Internet > > > > >IP real time streams cross borders between different administrativ= e > > >domains, (e.g.VoIP VPNs embedded in Telco IP backbones,enterprise > > >intranets). The address of MG in Domain A is not known in the Dom= ain B > > and > > >vice versa. A solution for IPv4 and it's restricted address space= is > > >required. > > > > > >For a Call from Domain A into Domain B on a per call basis the MGC= > > >has to select the ports on the "IP/IP MG" > > > > > >Christian > > > > Support NetAid! http://www.netaid.org > > -------------------------------------------------- > > Chip Sharp Consulting Engineering > > Cisco Systems Telco Bio-region > > Reality - Love it or Leave it. > > -------------------------------------------------- Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. -------------------------------------------------- = --0__=0QdXVYpTQpSjCKy2pU4mfVnGOpVBzUb83wbnjl2hB9z5um4TiffcJPgt-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 17 20:26:51 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07905 for ; Fri, 17 Mar 2000 20:26:51 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7A7D8B00@standards.nortelnetworks.com>; Fri, 17 Mar 2000 20:22:12 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 93527 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 17 Mar 2000 20:20:29 -0500 Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D769E9A0@standards.nortelnetworks.com>; Fri, 17 Mar 2000 20:10:29 -0500 Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id DAA22441; Sat, 18 Mar 2000 03:14:48 +0200 (EET) Received: from daebh01nok.americas.nokia.com (daebh01nok.americas.nokia.com [172.18.242.182]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id DAA04882; Sat, 18 Mar 2000 03:14:47 +0200 (EET) Received: by daebh01nok with Internet Mail Service (5.5.2448.0) id <1RMJAZKR>; Fri, 17 Mar 2000 19:13:47 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Fri, 17 Mar 2000 19:13:17 -0600 Reply-To: Melinda.Shore@NOKIA.COM Sender: "Media Gateway Control (megaco)" From: Melinda.Shore@NOKIA.COM Subject: Re: "IP/IP" Media gateways? X-To: jsegers@lucent.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM > From: EXT John Segers [mailto:jsegers@lucent.com] > Sent: Friday, 17 March, 2000 8:09 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: "IP/IP" Media gateways? > The box you labeled "IP/IP MG" is, according to your description a NAT > device. I believe that ETSI TIPHON has started requirements work on > controlling NATs in the media path of calls. Maybe megaco > can meet the requirements for this IP/IP GW application. Certainly the question of whether or not MGCP and/or megaco would be suitable for controlling NATs etc. has come up repeatedly (and let's not forget Christian's now-expired draft on using MGCP to control "packet relays"). If someone wants to come to the foglamps BOF in Adelaide and argue for using a media gateway control protocol, I'd be happy to slot you in for, say, 10-15 minutes. Does someone have a start on a package? Melinda -- Melinda Shore Nokia IP Telephony 127 W State St Ithaca, NY 14850 +1 607 273 0724 x81 (work) +1 607 227 4096 (mobile) +1 607 275 3610 (fax) Melinda.Shore@nokia.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sat Mar 18 11:29:52 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19700 for ; Sat, 18 Mar 2000 11:29:52 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9BA3BAB0@standards.nortelnetworks.com>; Sat, 18 Mar 2000 11:25:04 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 94069 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 18 Mar 2000 11:23:04 -0500 Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.53C9B780@standards.nortelnetworks.com>; Sat, 18 Mar 2000 11:23:04 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id RAA10616 for ; Sat, 18 Mar 2000 17:27:25 +0100 (MET) 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 RAA25875 for ; Sat, 18 Mar 2000 17:27:25 +0100 (MET) Received: from ericsson.com (arael25m100.ericsson.se [130.100.251.229]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id RAA17628 for ; Sat, 18 Mar 2000 17:27:22 +0100 (MET) X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <852568A4.0050AE6C.00@notes950.cc.telcordia.com> <38D15F82.5C3BBF29@ericsson.com> <38D249A1.C524FEE7@inet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38D3A548.A552E3D7@ericsson.com> Date: Sat, 18 Mar 2000 16:48:24 +0100 Reply-To: Stephen Terrill Sender: "Media Gateway Control (megaco)" From: Stephen Terrill Organization: L.M. Ericsson Subject: Re: Comments on MEGACO protocol To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi Mart & Selvam, Selvam has pointed out the the decision of the Q.2941.3 and H.248 is on the same day, so we are in a position to update the reference as I see it - if we view this as an editorial update or correction. Perhaps that is the best way forward?? Regards, ..//Steve Mart Nurmet wrote: > Stephen: > > If and when Q.2941.3 (along with the other BICC related standards) are approved at the Special meeting of SG 11 on June 15 can the reference be changed? Or should we wait till that happens? > > Stephen Terrill wrote: > > > Hi, > > > > The reason that this suggestion was not followed in the first place was for reasons of the referencing rules. A determined document is not allowed to reference a not determined document (like an RFC reference and I-D). I am not sure of the timing of the SG-11 decision cf the SG-16 decision of H.248. If it allows for this, then it might be OK, otherwise other solutions should be sought. > > > > Selvam Rengasami wrote: > > > > > Folks, > > > > > > One correction to my previous e-mail. > > > > > > If we accept my proposal, then we should consider changing the reference from > > > Q.2941.1 to Q.2941.3 in C.8 > > > > > > Cheers, > > > > > > -Selvam > > > > > > Selvam Rengasami on 03/16/2000 09:41:23 AM > > > > > > Please respond to Selvam Rengasami > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > cc: (bcc: Selvam Rengasami/Telcordia) > > > Subject: Re: Comments on MEGACO protocol > > > > > > Christian, John, > > > > > > I think the issue that Keith is raising is an interesting one. Q.2941.1 defines > > > a generic mechanism for transporting an identifier via the GIT in DSS2. As > > > Keith points out, in general, the GIT length is not limited by Q.2941.1, > > > therefore 4 or even 6 octets is not enough, if we want to support the generic > > > mechanism. > > > > > > Now, if we want to support the BNC-ID mechanism (e.g., for use in conjunction > > > with BICC), then Q.2941.3 defines how a BNC-ID is carried in the GIT. Q.2941.3 > > > constrains the GIT length for BNC-ID value to exactly four octets (no more, no > > > less). Specifically, Q.2941.3 gives the coding for Octet 5 (which identifies > > > BICC [Q.1901] and for Octet 6 indicates that the identifier is a BNC-ID. In > > > addition, Octet 6.1 (the length of the identifier) is required to be coded to a > > > value of 4. Finally octets 6.2 through 6.5 provide the four octet BNC-ID value. > > > > > > If we want to allow for future variations in Q.2941.3 or even Q.2941.1, then we > > > may want to consider allowing more than four octets for the BIR in C.8. > > > > > > I am basically interested in having the BNC-ID value (as defined by Q.2941.3) > > > signaled between the MGC and the MG. Four octets would suffice for this > > > purpose. I propose that we agree that the BIR for C.8 can only contain the > > > BNC-ID value as defined in Q.2941.3 (i.e., octets 6.2 through 6.5) which > > > requires no change to the document. > > > > > > By the way, Q.2941.3 (along with the other BICC related standards) is scheduled > > > to be approved (decided) in the Special meeting of SG 11 on June 15. > > > > > > Cheers, > > > > > > -Selvam Rengasami > > > > > > Telcordia Technologies > > > > > > Tel: +1 732 758 5260 > > > E-mail: srengasa@telcordia.com > > > > > > Christian Groves on 03/15/2000 06:58:59 PM > > > > > > Please respond to Christian Groves > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > cc: (bcc: Selvam Rengasami/Telcordia) > > > Subject: Re: Comments on MEGACO protocol > > > > > > G'Day John, > > > > > > The property name is BIR. > > > > > > Perhaps the following change might work? > > > > > > BNCid 8000 6 OCTETS GIT (Generic Identifier Transport) > > > BNCid (Octet 5a and above) > > > Ref.: Recommendation Q.2941.1 (09/97) > > > > > > Cheers, Christian > > > > > > John Segers wrote: > > > > > > > > Christian, > > > > > > > > I believe it makes sense when it is used for binding reference. If we > > > > only use octet 5 and above, and only use the GIT parameter for this > > > > specific case, we should rethink the name of the parameter. Using GIT > > > > with a reference to Q.2941.1 will undoubtedly lead to confusion. > > > > > > > > John > > > > > > > > Christian Groves wrote: > > > > > > > > > > G'Day Keith and John, > > > > > > > > > > Regarding 6 the intention was to use this as a binding reference > > > > > (BNCid). Annex C should refer to octet 5 and above. For the BNCid the > > > > > length as per the GIT would be 6 octets. Make sense? > > > > > > > > > > Cheers, Christian > > > > > > > > > > John Segers wrote: > > > > > > > > > > > > Keith, > > > > > > > > > > > > Most of the changes you request are ok. There's a couple that I don't > > > > > > know about: > > > > > > - (Re. 3) I thought that references to ITU Rec. have to be specific > > > > > > (i.e., including a date). I asked Glen, and he's not sure either. > > > > > > We'll check. > > > > > > - (Re. 5) What headers are missing according to you? The current ASN.1 > > > > > > starts with "MEDIA-GATEWAY-CONTROL DEFINITIONS AUTOMATIC TAGS::=". I > > > > > > checked the syntax with the OSS tools and didn't find a problem. > > > > > > - (Re. 6) I believe this was brought in through MSF and I never > > > > > > checked. Having looked up Q.2941.1 now, I agree that 4 octets is > > > > > > restrictive. > > > > > > > > > > > > John > > > > > > > > > > > > "Drage, Keith" wrote: > > > > > > > > > > > > > > Attached please find a number of editorial comments on the Geneva output > > > > > > > document, which we also understand is identical to the MEGACO last call > > > > > > > document. These points are not intended to be controversial. In the > > > event > > > > > > > that discussion is required to resolve such a comment, then we will > > > withdraw > > > > > > > the comment in order to allow the document to proceed. > > > > > > > > > > > > > > 1) Abbreviations. "BRI" is never used and therefore should be > > > removed > > > > > > > from the list of abbreviations. > > > > > > > > > > > > > > 2) References. Q.724 is never used and should be removed. > > > > > > > > > > > > > > 3) References and annex C. Where a reference is only used in annex > > > C, > > > > > > > we believe in general in most cases these should be undated (i.e. the > > > latest > > > > > > > version of the referenced document applies). This in particular applies > > > to > > > > > > > Q.931, Q. 2931, Q.763 where ITU-T SG11 have no intention of changing > > > > > > > codepoints to different values, but do reserve the right to add new > > > values. > > > > > > > Surely the whole ethos of annex C is that new values do get > > > automatically > > > > > > > incorporated. > > > > > > > > > > > > > > 4) References (and annex C if comment 3 not accepted). Some of the > > > > > > > dates are incorrect. Q.761-4 have a date of December 1999 as that was > > > > > > > decided last year. Q.2931 should reflect the date of the latest > > > amendment > > > > > > > (4) which we believe is also December 1999. > > > > > > > > > > > > > > 5) Annex A. We could not find the module header, or an exports > > > > > > > statement, for the ASN.1. The module header is mandatory parts of the > > > ASN.1, > > > > > > > and gives that module an object identifier, which is needed for inport > > > to > > > > > > > anything else. > > > > > > > > > > > > > > 6) Annex C, C.8, generic identifier transport. We are not sure how > > > you > > > > > > > fit this into four octets. Is there some subset of the generic > > > identifier > > > > > > > transport information element that is being used? Various codings of > > > this > > > > > > > information element get very, very long. > > > > > > > > > > > > > > 7) Annex C, C.9, ITC has a reference to a note 2, which is not in > > > the > > > > > > > table. Is this a spurious inport from the referenced standard? If so, we > > > > > > > believe it can be deleted. > > > > > > > > > > > > > > 8) Annex C, C.9. References to Q.931 need to identify that the > > > > > > > references are to the encoding in the Bearer capability information > > > element, > > > > > > > and not to the Low layer information element. The latter has identical > > > > > > > fields with the same code values, but has a more extensive range of > > > values > > > > > > > assigned. This is because some values (particularly at layer 3) are only > > > > > > > defined for end user to addressed end user usage. I believe in H.248 > > > only > > > > > > > the more restricted list in the Bearer capability information element > > > would > > > > > > > be valid. > > > > > > > > > > > > > > Keith Drage > > > > > > > > > > > > > > > --------------------------------------------------------------- > > > > > > > > Keith Drage (keith.drage@siemenscomms.co.uk) > > > > > > > > Siemens Communications Limited, > > > > > > > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > > > > > > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > > > > > > > --------------------------------------------------------------- > > > > > > > > Internet communications are not secure and therefore Siemens > > > > > > > > Communications Limited does not accept legal responsibility for the > > > > > > > > contents of this message. Any views or opinions presented are solely > > > those > > > > > > > > of the author and do not necessarily represent those of Siemens > > > > > > > > Communications Limited unless otherwise specifically stated. > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > John Segers email: jsegers@lucent.com > > > > > > Lucent Technologies Room HE 306 > > > > > > Dept. Forward Looking Work phone: +31 35 687 4724 > > > > > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > > > > > > > > -- > > > > John Segers email: jsegers@lucent.com > > > > Lucent Technologies Room HE 306 > > > > Dept. Forward Looking Work phone: +31 35 687 4724 > > > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sat Mar 18 17:52:36 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12518 for ; Sat, 18 Mar 2000 17:52:35 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0AC66700@standards.nortelnetworks.com>; Sat, 18 Mar 2000 17:47:34 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 94465 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 18 Mar 2000 17:46:07 -0500 Received: from PMESMTP02.wcom.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.707D7180@standards.nortelnetworks.com>; Sat, 18 Mar 2000 17:36:06 -0500 Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FRN0068J2ZGNW@firewall.mcit.com> for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 18 Mar 2000 22:40:28 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0FRN004012ZFHG@dgismtp02.wcomnet.com>; Sat, 18 Mar 2000 22:40:27 +0000 (GMT) Received: from omzmta01.mcit.com ([166.37.214.7]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0FRN004382ZE2B@dgismtp02.wcomnet.com>; Sat, 18 Mar 2000 22:40:26 +0000 (GMT) Received: from C25776A ([166.44.60.147]) by omzmta01.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000318224021.EQZK21918@C25776A>; Sat, 18 Mar 2000 22:40:21 +0000 MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: multipart/mixed; boundary="Boundary_(ID_oHcIbii8TF1CP0IU78yAEg)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: Date: Sat, 18 Mar 2000 16:40:19 -0600 Reply-To: henry.sinnreich@wcom.com Sender: "Media Gateway Control (megaco)" From: Henry Sinnreich Subject: Re: "IP/IP" Media gateways? X-To: Melinda.Shore@NOKIA.COM X-cc: dale.drew@level3.com, schulzrinne@cs.columbia.edu, Jonathan Rosenberg DynamicSoft To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: This is a multi-part message in MIME format. --Boundary_(ID_oHcIbii8TF1CP0IU78yAEg) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit "Getting SIP through Firewalls and Nats" seems a pretty good approach. Have attached it here since it is not yet in the archive. Is there a presenter and slot for it? Henry Henry Sinnreich MCI WorldCom 400 International Parkway Richardson, Texas 75081 USA >-----Original Message----- >From: Media Gateway Control (megaco) >[mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of >Melinda.Shore@NOKIA.COM >Sent: Friday, March 17, 2000 7:13 PM >To: MEGACO@STANDARDS.NORTELNETWORKS.COM >Subject: Re: "IP/IP" Media gateways? > > >> From: EXT John Segers [mailto:jsegers@lucent.com] >> Sent: Friday, 17 March, 2000 8:09 AM >> To: MEGACO@STANDARDS.NORTELNETWORKS.COM >> Subject: Re: "IP/IP" Media gateways? > >> The box you labeled "IP/IP MG" is, according to your >description a NAT >> device. I believe that ETSI TIPHON has started >requirements work on >> controlling NATs in the media path of calls. Maybe megaco >> can meet the requirements for this IP/IP GW application. > >Certainly the question of whether or not MGCP >and/or megaco would be suitable for controlling >NATs etc. has come up repeatedly (and let's >not forget Christian's now-expired draft on using >MGCP to control "packet relays"). If someone >wants to come to the foglamps BOF in Adelaide and >argue for using a media gateway control protocol, >I'd be happy to slot you in for, say, 10-15 minutes. >Does someone have a start on a package? > >Melinda >-- >Melinda Shore >Nokia IP Telephony >127 W State St >Ithaca, NY 14850 >+1 607 273 0724 x81 (work) >+1 607 227 4096 (mobile) >+1 607 275 3610 (fax) >Melinda.Shore@nokia.com --Boundary_(ID_oHcIbii8TF1CP0IU78yAEg) Content-type: text/html; CHARSET=US-ASCII; name=draft-rosenberg-sip-firewalls-00.htm Content-disposition: attachment; filename=draft-rosenberg-sip-firewalls-00.htm Content-Transfer-Encoding: quoted-printable

Internet Engineering Task Force SIP WG Internet Draft J.Rosenberg,D.Drew,H.Schulzrinne draft-rosenberg-sip-firewalls-00.txt dynamicsoft,Level 3,Columbia U. February 22, 2000 Expires: July, 2000 Getting SIP through Firewalls and NATs STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document discusses the interaction of the Session Initiation Protocol (SIP) with with Network Address Translators (NATS) and firewalls. We show the difficulties in SIP traversing these devices, and we compare the solutions that might be used. 1 Introduction The Session Initiation Protocol (SIP) [1] is a general purpose tool for the initiation, modification, and termination of sessions. As a core part of its functionality, SIP must carry around the ports, IP addresses and domain names needed to describe the sessions it controls. It also causes session traffic to be established (for example, RTP [2] streams with audio and video), often on dynamic UDP ports. As such, there are two issues in getting SIP to traverse NATs J.Rosenberg,D.Drew,H.Schulzrinne [Page 1] =0C Internet Draft SIP Firewalls February 22, 2000 and firewalls. The first is getting SIP itself through, and the second is getting the media sessions it initiates through. The latter is byfar the harder problem. Section 6.40.1 of RFC 2543 briefly discusses some of these issues, but not in detail. This document serves to fill that void by discussing the problems at length, and by proposing numerous architectural solutions, all of which are already enabled by SIP. In Section 2, we define what we mean by firewalls and NATs. In Section 3, we discuss the two scenarios in which SIP and firewalls may interact - internal service, whereby the private network has SIP deployed, and external service, where it does not. Then, in section 4, we identify the numerous problems in getting SIP to traverse a NAT or firewall. Section 5 discusses the two configurations that can be used to address those problems. Section 6 goes through the detailed SIP processing required in both configurations. Finally, Section 7 discusses what we believe are "non-solutions" to the problem. 2 Definitions 2.1 Firewalls Our definition of a firewall parallels that defined by N. Freed in [3]. A firewall as a device with two interfaces - one on the "inside" and one on the "outside". Its function is generally to protect devices on the inside from those on the outside, and to sometimes prevent users on the inside from connecting to, or accessing, services on the outside. Firewalls generally come in two flavors. Protocol-end-point firewalls (also known as application firewalls) act as entities for a particular set of application layer protocols. This means they terminate an application layer protocol on one interface, and re- initiate it on another. Application layer firewalls are generally required to implement some subset of the protocol. Their function in this capacity is to implement some safe subset of the protocol, perform validity checks, and possibly authenticate users at the application layer. The second flavor of firewall is a packet filter firewall. These firewalls do not attempt to terminate application layer protocols. They operate purely at the IP and UDP/TCP layer. A packet filter firewall applies a set of rules and policies to packets received on both interfaces to selectively discard packets. There is no standard set of rules and policies - they are at the discretion of the firewall administrator. However, we observe that several policies tend to be common: J.Rosenberg,D.Drew,H.Schulzrinne [Page 2] =0C Internet Draft SIP Firewalls February 22, 2000 o The firewall lets no UDP packets in or out. TCP packets are not allowed in unless they are destined for specific servers designated to handle the protocol (for example, the designated http server can receive TCP packets on port 80). TCP packets are allowed out, so that users on the inside can connect to servers on the outside. TCP packets coming in that are associated with a connection opened from inside the firewall are also allowed in. o Same as the previous, except that only specific TCP port numbers are allowed out; typically this includes SMTP, FTP, telnet and HTTP. o Same as the previous, except that only specific connections with given TCP port numbers from specific hosts are allowed out. This means that users must connect to HTTP proxies inside of the firewall, and that SMTP is allowed only from designated mail relays, for example. 2.2 NATs A NAT is a logical function, usually embedded in a border router which straddles a public and private network, that translates IP address information from packets which traverse the boundary. Its main application is to hide internal IP addresses of the private network. This is done to avoid renumbering the private network when providers change, to allow a large address space inside the private network to be mapped to a smaller set of addresses on the outside, or to provide privacy. NATs have become popular tools, especially within home networks and small corporate enterprises which cannot afford to purchase large public address spaces. NATs are stateful devices. They generally require a table to be established listing the active sessions. For each session, the particular bindings and translations are stored. Sessions are either removed explicitly through packets (a TCP FIN, for example, removes TCP session state), or are timed out after an extended period (as is always the case for UDP services). Since NATs operate at the IP and transport layers, they fail when application layer protocols include IP addresses and ports within their payloads. In these cases, Application Layer Gateways (ALGs) must be deployed instead. These devices have awareness of the particular application, and can translate addresses within message bodies. The address mappings provided by NAT can be dynamic or static. In dynamic mappings, the set of available addresses is stored in a J.Rosenberg,D.Drew,H.Schulzrinne [Page 3] =0C Internet Draft SIP Firewalls February 22, 2000 table. As new sessions are established, they are assigned one of these addresses. When the session terminates, the address is returned to the free table. In static mappings, there is a one to one correspondence of internal, private addresses, with external, public ones. NATs come in a variety of types, with each type providing different services and functions. RFC 2663 [4] overviews these different types. We review them here, briefly, to facilitate subsequent discussion. The types of NATs are: Traditional NAT: Also known as outbound NAT, these NATs allow communications that are initiated from the private network to the external network. These devices generally translate the source IP address (and possibly port) of outgoing packets, and the destination address (and possibly port) of packets coming back into the private network for the same session. Basic NAT: A Basic NAT is a type of traditional NAT. It only translates IP addresses, not ports. Network Address Port Translator (NAPT): NATPs also translate the source port for outgoing packets and destination port for incoming. This allows multiple sessions to be mapped into a single IP address by using the source port as a session identifier. This type of device is extremely useful for home networks connected to a cable modem or DSL line that provides a single IP address. Bi-Directional NAT: Also known as two-way NAT, these devices allow hosts in the external network to initiate sessions to hosts on the internal network. This is accomplished by deploying a DNS ALG which creates address bindings when external hosts contact DNS for the address of an internal host. Twice NAT: Twice NAT is used when the address space within the private network overlaps with the address space of public addresses on the external network. With twice NAT, sessions initiated from inside the private network require translation of both the source and destination IP addresses. They also require a DNS ALG. See RFC 2663 [4] for more details. A related technology, called Realm Specific IP (RSIP) [5] also allows a private network with private addresses to communicate with external J.Rosenberg,D.Drew,H.Schulzrinne [Page 4] =0C Internet Draft SIP Firewalls February 22, 2000 hosts. Unlike NAT, RSIP requires clients to be aware of the differing address realms internally and externally. Whenever they wish to contact and external host, clients connect to an RSIP server to obtain an address within the external name space. In the discussions which follow, we do not consider twice NAT or Realm Specific IP. 3 Scenarios with SIP A SIP network consists of proxies, redirect servers, registration servers and user agents. For the purposes of discussion, we collectively call redirect, registration and proxy servers "SIP servers". The distinction between the three is not particularly relevant for purposes of the firewall discussion. In order to receive calls, a user must generally be a customer of a "SIP Provider"; this SIP provider allows the user to register with a SIP server, and receive incoming calls through the SIP server. Outgoing calls may also be made through this server, but it is possible for a user to make outgoing calls without a SIP provider. A user can even receive calls without a SIP provider, but this requires the calling party to know the IP address or hostname of the called party. This knowledge is unlikely in real deployments. A SIP provider is not necessarily the same as the network access provider for a particular user. In fact, for residential customers, there is a strong trend towards the separation of access services (provided through traditional ISPs like MCI and AT&T Worldnet), and application services, such as email, web, and instant messaging, provided by application service providers (ASPs) like Yahoo and AOL (of course AOL is also an ISP). VoIP service, enabled by SIP, is another example of an application an ASP might provide. The problem of getting SIP through firewalls and NATs generally only occurs when the user's access provider is a corporate network. Residential ISPs almost never deploy firewalls, nor do universities [1] which follow, we assume that the access provider is a corporate network. Given this, there are two configurations of interest when getting SIP through a firewall. The first is when the user wishes to use SIP services from some ASP, independently of whether their corporate network or ISP is providing SIP services. We call this first scenario external service. The second scenario is when the corporate network _________________________ [1] The authors strongly recommend changing ISPs if your residential ISP has a firewall. J.Rosenberg,D.Drew,H.Schulzrinne [Page 5] =0C Internet Draft SIP Firewalls February 22, 2000 is also acting as a SIP ASP (we call this internal service). 3.1 External Service The configuration for external service is shown in Figure 1. | | +-----+ +----+ +-----+ | SIP | | FW | | SIP | | UA | +----+ | Svr | +-----+ | +-----+ | inside | outside | Network X | Network Y Figure 1 This scenario arises when a user is connected through some network X (usually a corporate intranet), and wishes to use SIP services from some SIP ASP Y, external to X, and X is using a firewall. Generally, firewalls are deployed in corporate enterprises, and enterprise users tend not to make use of external ASPs for services. Rather, these services are available inside of the firewall, so that they can be managed by the enterprise. This configuration therefore occurs in cases where the enterprise has not deployed the service, but employees of the enterprise wish to make use of it through external providers. It also occurs when individual users, for non-business reasons, wish to access service from an outside provider even though it is provided as a service inside the enterprise. As it turns out, providing SIP services in this scenario, without adding SIP awareness to the firewall, is nearly impossible (without seriously hacking protocols, at least) with any but the most forgiving firewall. The reason is not SIP itself, but the media sessions which are initiated by SIP. Unless the firewall is willing to act as a proxy for external services (see Section 5.1), the firewall is not likely to let the media in or out of the firewall. This scenario is best solved using a proxy co-located with a firewall, described below in Section 5.1. J.Rosenberg,D.Drew,H.Schulzrinne [Page 6] =0C Internet Draft SIP Firewalls February 22, 2000 3.2 Internal Service The second configuration occurs when SIP is deployed within the corporate network. In this case, the SIP servers for the user exist on the inside of the firewall, and other network servers belonging to other providers are on the other side. This configuration is shown in Figure 2. | +-----+ +-----+ +----+ +-----+ | SIP | | SIP | | FW | | SIP | | UA | | Svr | +----+ | Svr | +-----+ +-----+ | +-----+ | inside | outside | Network X | Network Y Figure 2 This scenario can be handled with either a proxy co-located with the firewall/NAT, or with a firewall/NAT controlling proxy. 4 Problems in Traversing Firewalls and NATs Numerous issues need to be considering when using SIP through a firewall or NAT. Both devices come in two general types - network layer or application layer. Network layer devices do not look at the application protocol. Their rules and processing are purely based on IP and/or UDP/TCP processing. Application layer devices operate based on detailed knowledge of the application layer protocol. Many of the issues in getting application layer protocols to traverse NATs are discussed in [6]. This document refers to application layer NAT devices as Application Layer Gateways, or ALGs. Based on the guidelines in [6], there are numerous problems in getting SIP through a NAT without an ALG, many of which also pertain to firewalls. These issues are discussed in the subsections which follow. J.Rosenberg,D.Drew,H.Schulzrinne [Page 7] =0C Internet Draft SIP Firewalls February 22, 2000 4.1 Session Bundling The NAT friendly application design guidelines [6] recommends against protocols which provide session bundling; that is, they use a single session as a control channel for other sessions. SIP, fundamentally, is a control channel for establishing other sessions (namely, the media sessions). These kinds of protocols (of which FTP is another example) cause problems for NATs, since the addresses for the established sessions are in the body of the application layer messages. When used with SDP [7], SIP messages carry the IP addresses and ports that will be used for the media sessions. There may be multiple media sessions within a particular SIP call. Since SDP carries IP addresses and not host names, the external UA will send media to an IP address that is not globally routable. Therefore, media will not flow in the direction of external to internal. A nearly identical problem exists for firewalls. When a user inside the firewall sends media to an address outside the firewall, it will be dropped by the firewall unless a rule is established to allow it to traverse. Unfortunately, SIP does not mandate that SDP be used exclusively (although all implementations must support it). Future session description formats may be defined. 4.2 IP addresses within Packets Numerous SIP headers contain fields that can carry either IP addresses or domain names. These can cause problems for both firewalls and NATs. The Contact header in SIP requests and responses contains a SIP URL. SIP URLs can contain an IP address or a hostname. This address is used for signaling in the reverse direction which is part of the same SIP call. In the case of a NAT, if an IP address is present, the signaling will not be routed correctly from the external network to the private network. If a hostname is present, standard DNS ALGs can provide a translated address through the DNS query, avoiding the need for translation within SIP. If a firewall is in use rather than a NAT, the signaling may not traverse if a rule is not established in the firewall to allow the SIP messages through. In the case of internally provided SIP services, it is easy to configure such a rule. This rule would allow all UDP and TCP traffic on port 5060 to the IP address(es) of the proxies. These proxies form a "buffering zone", performing various checks and validations on the SIP messages, J.Rosenberg,D.Drew,H.Schulzrinne [Page 8] =0C Internet Draft SIP Firewalls February 22, 2000 and acting as a buffer for DoS attacks. However, in the case of external services, the firewall rule cannot include a destination IP address. This significantly worsens the protection provided. The Record-Route and Route headers in SIP requests have the same issues as the Contact header. When present, they indicate routing instructions for subsequent messaging. Should these include SIP URLs that contain IP addresses from the private network, signaling will not be routed correctly from the external network to the private network in the case of a NAT. In the case of a firewall, rules allowing traffic to be sent to the proxy must be installed. The Request URI in SIP requests contains a SIP URL. This may contain an IP address. For calls made from the internal network to outside the network, there is no problem, as this address refers to an external host with a public address [2] external network internally, the request URI will usually not contain an IP address (most users do not publish IP addresses within SIP URLs). If an IP address were present, it would have to have been the result of a domain name lookup external to the network. If a NAT were in use, a DNS ALG will allow queries for the IP address of a host within the network to return a globally routable IP address. This implies that special processing, beyond DNS ALGs, is not needed for request URI handling. Similarly, a firewall will need to be configured to allow SIP traffic destined for a proxy internal to the network, in the case of internally provided service. The Via headers in SIP requests contain IP addresses. These addresses are used to forward responses. Fortunately, SIP supports receiver tagged via fields. If a request arrives from a host, and the source IP address in the packet containing the request does not match the address in the Via field, the proxy tags the Via field with the source IP address. This address is used to send responses. This feature means that the Via field does not need to be translated through NATs. However, the responses are sent to the port in the Via field, *not* the source port of the message. This means that changes to the port numbers, made by NAPTs, will cause responses to be misrouted. To traverse a firewall, it is configured with a rule that allows SIP traffic in destined for the proxy on the inside of the network, as in the cases above. The Call-ID in a SIP request is required to be globally unique. It is constructed by appending some identifier to the IP address or hostname of the machine where the call originated. This address _________________________ [2] We do observe that this is a potential problem for twice NAT, however J.Rosenberg,D.Drew,H.Schulzrinne [Page 9] =0C Internet Draft SIP Firewalls February 22, 2000 itself is never needed for message routing. However, if the internal network is using one of the three private address spaces (10/8, 172.16/12 or 192.168/16), it is possible that the Call-ID won't be globally unique. This is because hosts within other private networks might use the same IP addresses. Should two users in two different private networks, both using the same private address, choose the same identifier, and then call the same user, incorrect call handling will take place. The SIP specification does mandate that if the host portion of the Call-ID is not globally routable, the local indentifier must be globally unique, so this should hopefully never happen. The To and From fields in SIP requests contain SIP URLs, which may contain IP addresses. If a Contact header is not present in the INVITE from a host in the private network, the From field will be used for routing subsequent requests from the called party. If the URL in the From field contains an IP address, these will not be routed properly in the case of NAT. However, most implementations do place a Contact header in the INVITE. Furthermore, since the From and To fields are used for identification of the parties, they generally contain domain names and not IP addresses. Of course, the protocol does not guarantee this. 4.3 Lifetime Issues When an INVITE message passes through a NAT (and an address binding is established for it) or through a firewall (and rules are created for the media streams), state is established. This state must eventually be cleaned up. For applications that run over TCP, closure of the TCP connection is usually a good indicator of the termination of the application. However, SIP can run over UDP. Thus, determination of when it is safe to destroy state must be done through application level awareness. Unfortunately, an INVITE transaction can last a very long time, as can a call. As a result, it is possible that some state is destroyed before the transaction and/or call actually completes. In the case of a NAT, the most problematic case for SIP itself (as opposed to the media session) is the IP addresses in the Via field. The received-by parameter in the Via header is populated with the address that will be used to send the response. This address is only valid for the lifetime of the binding. If the binding should expire before the response arrives, the transaction will fail. However, INVITE transactions do not last for more than a minute in the general case. A sufficiently long timeout should ensure this is not a problem. SIP calls, however, can be for a very long duration (on the order of J.Rosenberg,D.Drew,H.Schulzrinne [Page 10] =0C Internet Draft SIP Firewalls February 22, 2000 hours). Using a set timeout is likely to cause the binding to be lost before the call is complete. If this happens, the name to address bindings obtained from the DNS ALG will be stale. If the DNS ALG returns addresses with very small TTLs, this problem disappears. In that case, the usage of UDP is not problematic; IP address bindings can be re-established for each request (assuming all fields in the SIP message are domain names and not IP addresses). For the media session, if a NAT times out the address binding, or a firewall removes the rule that allows the media to pass, but the call is not over, the media will not flow and the call will appear as some kind of defect to the user. SIP can also run over TCP. NATs assume that the IP address bindings have a lifetime equal to that of the TCP connection. In SIP, clients are allowed (and most do) to close the TCP connection to the server once the transaction is complete, even though the call is still in progress. This means that the first problem identified above, whereby the receiver tagged Via fields become invalid if the binding changes before the transaction completes, is avoided with TCP. However, the NAT must be application aware and know not to time out the bindings until the call is actually over. 4.4 Multicast D.Senie [6] indicates that multicast does not run well through NAT, and an ALG is required. SIP can make use of multicast for both registrations (its most useful application) and INVITE messages. Generally these run on a well known multicast address, 224.0.1.75. 4.5 Security SIP is secured through both hop-by-hop mechanisms and end-to-end mechanisms. RFC2543 does not mandate a particular hop-by-hop security mechanism; both IPSec and TLS are mentioned. As pointed out in [6], IPSec does not traverse NATs, and TLS is recommended. Therefore, implementations using IPSec for SIP will fail, with or without an ALG. IPSec for SIP through a firewall should work, however, the firewall will not be able to determine the ports used for the media, in order to open up holes in the firewall. The end-to-end mechanisms in SIP provide both authentication and encryption. Both are problematic for NATs, including ALGs. The authentication mechanisms are not a problem for firewalls, but the end to end encryption is a problem for NAT. The authentication mechanisms, in particular PGP, sign several fields of the SIP request, including the body. The body, usually SDP, J.Rosenberg,D.Drew,H.Schulzrinne [Page 11] =0C Internet Draft SIP Firewalls February 22, 2000 contains the IP addresses and ports used for the media session. A NAT acting as an ALG will need to change the IP addresses in the SDP. Unfortunately, this will cause the signature to become invalid, and the message to be rejected. As a fix for this, SIP allows for messages to be resigned. The re- signing party removes the Authorization and Proxy-Authorization headers, resigns them, resulting in new headers, and inserts these into the message. The re-signer then includes their identifier (as a URI) which can be used to obtain the re-signer's certificate. A NAT handling outgoing requests should generally resign the message using the key of the organization itself. This not only solves the authentication problem; it also makes signature verification more realistic. It's much more likely an individual will have access to the certificate for an organization than an individual within that organization. However, signatures on responses to outgoing requests are very problematic. As responses are forwarded to the internal network by the NAT ALG, the headers may need to be replaced. This would be necessary if the From field or Record-Route in the request was replaced, in which case the original version needs to be put back in the response. Though the NAT ALG could resign the response, this doesn't make sense, since it is not from the same organization as the originator of the response. End-to-end encryption is much more problematic. It will cause several key headers and the body to be hidden from intermediate systems, including the SIP NAT ALG or firewall. This means the IP addresses cannot be determined or re-written, and holes in firewalls cannot be opened. As a result, the use of end-to-end encryption means that SIP will fail through any type of NAT or firewall. 4.6 Conclusion The conclusion of the analysis of this section is that SIP has several difficulties traversing NATs and firewalls. Most paramount among them is the presence of IP addresses for the media session in the bodies. Additionally, the possibility of IP addresses in the Contact, To, From, Record-Route and Route headers also means an ALG is needed to guarantee operation. 5 Architectural Solutions As a direct of the discussion in the previous section, there are two J.Rosenberg,D.Drew,H.Schulzrinne [Page 12] =0C Internet Draft SIP Firewalls February 22, 2000 solutions possible for allowing SIP through firewalls and NATs. One is to use an application layer firewall/NAT which understands SIP, and the other is to use a packet filtering firewall/NAT under the control of a proxy. 5.1 Colocation of Proxy and Firewall/NAT In this solution the firewall/NAT actually is co-located with a SIP proxy. This is shown in Figure 3. | +--------+ | +----+ | +-----+ | | FW | | | Net | | | NAT| | | SIP | | +----+ | | Svr | | SIP | +-----+ | PROXY | +--------+ | +-----+ +-------+ | +-----+| +-------+| | +-----+|| +-------+|| | | SIP ||| | SIP ||| | | UAs || |Proxies|| | +-----+ +-------+ | | INSIDE | OUTSIDE | Network X | Network Y Figure 3 Since the proxy and firewall/NAT are colocated, the proxy can have direct control over the firewall/NAT through some kind of internal API. This configuration is advantageous in that it need not rely on the existence of SIP servers within the network. Although Figure 3 shows proxies inside, the solution allows SIP to work when such proxies do not exist. This makes it the ideal solution for the J.Rosenberg,D.Drew,H.Schulzrinne [Page 13] =0C Internet Draft SIP Firewalls February 22, 2000 external services configuration. A corporate intranet can purchase a SIP enabled firewall, turn on the SIP support, and corporate employees can make use of external SIP services without deploying them internally, while still securing the internal network. 5.2 Firewall/NAT Controlling Proxy The solution of Section 5.1 has the drawback of burdening the firewall with an application layer protocol. As more applications get deployed, the firewall/NAT needs to become aware of all of them. This eventually may become difficult to manage and difficult to support within an enterprise network. As an alternative solution, the proxy and firewall/NAT can be separated, but a control protocol or API can be used between them. This protocol would allow the proxy to instruct a firewall to open and close holes for the media stream. It would allow the proxy to query a NAT for address bindings. This allows application layer information to be externalized from the NAT and firewall. This architecture is shown in Figure 4. | ............... | . +-----+ . +----+ +-----+ . |Proxy|xxxxxxxxxxxxxxxx| FW | | Net | . | | . control | NAT| | SIP | . +-----+ . protocol +----+ | Svr | . . | +-----+ . Buffer Zone . | ............... | | +-----+ +-------+ | +-----+| +-------+| | +-----+|| +-------+|| | | SIP ||| | SIP ||| | | UAs || |Proxies|| | +-----+ +-------+ | | INSIDE | OUTSIDE Figure 4 J.Rosenberg,D.Drew,H.Schulzrinne [Page 14] =0C Internet Draft SIP Firewalls February 22, 2000 By placing the application layer awareness in the proxy rather than firewall NAT, several advantages are obtained: o Since the NAT/firewall is focused on a single task - network layer forwarding and filtering, its performance can be optimized. It is not burdened with application layer processing. o As new applications are deployed, the NAT/firewall does not need to be upgraded. The application servers can control the NAT/firewall as well. This configuration also requires the firewall to have holes opened permanently for the SIP messaging itself from the proxy out, and from the outside in. This can be accomplished by configuring the proxies with a rule which only allows UDP and TCP on port 5060 to and from the IP address of the proxy (or proxies) inside the firewall. Such a configuration guarantees that the proxy inside the firewall is always the first point of contact for incoming messaging, and the last point of contact for SIP messages before they leave the network. These proxies are effectively part of a "Buffer Zone (BZ)" which exists on the inside of the network, granting access to users and services within. In the case of a NAT, the proxy in the BZ will need to reachable from outside. This is accomplished by using a DNS ALG that gives out globally routable IP addresses for the proxy when queries for its domain name are given. It is desirable for these addresses to be based on long lived bindings. The usage of a SIP BZ offers numerous advantages. First, it is a protection against DoS attacks involving flooding of messages. The BZ ensures that all SIP messages hit specially engineered proxy servers, rather than any machine within the network. These proxies can be configured with load checkers which cause error handling to take place when call volumes to any particular host within the network become too high. This error handling might involve rejecting all requests using a stateless mode. This prevents build up of state within the proxy and also protects the internal network. An additional advantage of the BZ is protection against spam. Certain URLs, known to be from malicious callers, can be rejected outright without bothering internal users at all. Finally, the BZ allows for message validation. Overly long requests can be rejected. Messages with mailicous Java applets can be detected and rejected. Poorly formed requests can be rejected, particularly ones with very long values for certain fields. J.Rosenberg,D.Drew,H.Schulzrinne [Page 15] =0C Internet Draft SIP Firewalls February 22, 2000 Clearly, this solution only applies when SIP servers are deployed within the corporate network. Several possibilities exist for the control protocol between the proxies and a firewall. One is SOCKS, specified in RFC 1928 [8] which is engineered for exactly this purpose. We know of no equivalent for NAT control, however. An additional level of scalability can be achieved by introducing an additional server, which we call a session manager. This device actually stores the call state and other information needed by the proxy servers. In this way, numerous proxy servers can be deployed rather than one. They access the session manager when they need access to call state. The precise way in which this is done requires further investigation. 6 Proxy/Firewall/NAT Operation Independently of whether the proxy and firewall/NAT are co-resident, there are specific goals to be achieved by the system: 1. Ensure that only authorized users inside the network may make outgoing calls. 2. Ensure that legitimate users outside the network may make calls into the network. 3. Ensure that calls make from outside the network to inside are not malicious or harmful to systems inside the network. 4. Ensure that any bodies carried in SIP messages (such as Java applets or Word documents) are virus free and not harmful to the system. 5. Ensure that media streams for the call are allowed to flow in and out of the network for the duration of the call only. 6. Ensure that users cannot be contacted without having SIP requests routed through the firewall. The operational procedures required to meet these objectives are outlined in the subsections below. 6.1 Outgoing Calls When a user makes a call, the proxy acts as a local outbound proxy. This can be accomplished by explicitly or automatically configuring J.Rosenberg,D.Drew,H.Schulzrinne [Page 16] =0C Internet Draft SIP Firewalls February 22, 2000 (through DHCP [9], SLP [10] or ACAP [11]) the local outbound proxy in user agents within the enterprise. This only works when SIP services are provided internally. Alternatively, when SIP services are external, the firewall/proxy can intercept SIP requests not explicitly destined for the firewall/proxy. Doing so requires care. The request needs to still be delivered to the server the user agent sent the request to. To accomplish this, the proxy/firewall notes the destination IP address in the request when the request is captured. When the request is forwarded, rather than determining the next hop server by looking up the host name in the request URI (the normal procedure if the request was actually sent directly to the proxy/firewall), the request is sent to the IP address that was noted previously. When an INVITE is received by the proxy from a host within the private network, and SIP service exists internally, it authenticates the caller by sending a 407 response. The UAC resubmits the request. If the credentials are valid, the firewall/proxy can check its policy database to determine if the user is authorized to make outgoing calls, and if so, forward the request based on normal SIP procedures. If SIP services are external, no authentication is performed; the request is simply forwarded by the proxy/firewall. In either case, the proxy also adds the Record-Route header. The proxy also remembers the SDP in the INVITE, and extracts the port numbers and IP addresses for each of the media streams. If NAT is in use, additional operations are performed by the proxy. The IP addresses and ports in the SDP are removed. A binding is created, mapping these address/ports to globally routed ones. This binding is created locally if the NAT and proxy are co-resident. Otherwise, some kind of query is needed to allow the proxy to ask the NAT for a binding. Assuming this is done, the globally routed addresses are inserted into the SDP. This may require the request to be resigned. If the Contact, From, or Record-Route headers contain IP addresses, bindings are created for those addresses as well (these may end up using the same bindings as the IP addresses in the SDP, but not necessarily. As an example, for a megaco [12] decomposed gateway, they will not), and the globally routed ones are placed into the message. If these fields contain hostnames, bindings of those hostnames to globally routed addresses must be done, and a DNS ALG configured to return those addresses when queries are made. The proxy inserts a Via header containing a globally routable IP address and port. If the From, Contact or Record-Route headers were replaced, these must be stored by the proxy. They must be reinserted into the response. When a response to the INVITE arrives from the external network, it goes through the firewall or NAT (assuming the previous steps have J.Rosenberg,D.Drew,H.Schulzrinne [Page 17] =0C Internet Draft SIP Firewalls February 22, 2000 been followed) and is examined by the proxy. If it is a 200 OK with SDP, the proxy analyzes the SDP, comparing with the one from the INVITE. For all media streams which were accepted by the UAS (the connection address is nonzero), the proxy notes the IP address and port indicated in the SDP in both the INVITE and 200 OK. The response is then forwarded. The proxy also opens holes in the firewall, if one is in use, to let the media traffic in and out on the ports and addresses obtained from the SDP in the INVITE and 200 OK. In particular, if the INVITE contained address A and port B for some media stream, and the 200 OK contained address X and port Y for the same media stream, the proxy/firewall allows UDP destined for address X and port Y from the inside to the outside of the firewall. Similarly, it allows UDP traffic from the outside to the inside if it is destined for address A and port B. The firewall may further restrict the source addresses; for example, allowing UDP traffic from the outside to the inside if its destined for address A and port B and is from address X. However, this assumes that the called party is using the same machine and interface to both send and receive media. This assumption is not valid for multi-homed hosts, or for multimedia systems with different components running on different hosts. Recent discussions on the SIP mailing list have proposed adding a source address to SDP in order to construct more restrictive firewall rules. In the case of a NAT, the original From, Contact and Record-Route headers are placed back into the response (note the Record-Route headers placed back will only replace a subset of those in the response). Nothing is done to the SDP for NAT. Replacing headers will invalidate signatures and the Authorization header must be removed, if present. Recent extensions to SIP allow for "early media" to be opened by including SDP in provisional responses [13] which are sent reliably [14]. As a result, the proxy will also need to look for these responses. The mechanism used to transmit these reliably is based on a new PRACK request. This request can also contain SDP. The firewalls will also need to look for these messages, extract the ports and IP addresses, and open holes based on them or create bindings for them, just as was done for the INVITE. PRACK messages are forwarded based on Record-Route headers returned in provisional responses; this means that the proxy will receive the PRACK messages so long as it inserted the Record-Route in the outgoing INVITE request (which it must do). The proxy can use proxy authentication to verify the authenticity of the PRACK messages as well, if SIP services exist internally. As a final complication, SIP allows for the INVITE to contain no media information. Rather, the 200 OK contains the receive J.Rosenberg,D.Drew,H.Schulzrinne [Page 18] =0C Internet Draft SIP Firewalls February 22, 2000 capabilities of the called party, and the ACK contains a trimmed subset, representing the capabilities and accepted media streams of the calling party. This requires the proxy to open the holes for media (or create bindings for them) on receipt of the ACK, rather than on receipt of the 200 OK as discussed above. 6.2 Incoming Calls The initial processing for incoming calls (from the external network to the internal network) depends on whether SIP services exist internally or not. 6.2.1 Incoming Calls for Internal Services The scenario for incoming calls is largely the reverse of the scenario for outgoing calls. The name space and DNS records must be configured so that all incoming requests for users within the private network arrive at the proxy. If the company is named foo.com, this implies that the SIP URLs published externally for employees of foo.com should be of the form sip:user@foo.com. DNS records must be configured so that a lookup of foo.com (using SRV and/or A records) results in the address of the firewall proxy (or proxies, when there are more than one to support load balancing and backups). SIP URLs are "published externally" through their placement on business cards and personal communications; managing this is outside the scope of this document. However, SIP URL's are also effectively "published" automatically through SIP REGISTER messages. Therefore, users must be prevented from sending external registrations to other servers listing Contact addresses that do not correspond to the address of the proxy/firewall. This is discussed in more detail in Section 6.7. Assuming the naming and records have been managed properly, an INVITE arrives at the proxy when a call is to be set up to a user inside the network. In the case of NAT, the NAT will have done nothing but rewrite the destination IP address of the packet to the private address of the proxy. All of the SIP level details regarding NAT processing are done in the proxy. Proxy authentication is probably not viable for incoming calls. This is because the domain of the caller is not the same as the domain of the called party. There is unlike to exist any kind of shared secrets between a server in one domain and a user in another. Widespread deployment of a PKI will enable proxy authentication for incoming calls, but it does not exist at the moment. 6.2.2 Incoming Calls for External SIP Service The scenario for incoming calls is very similar to outgoing calls. The external SIP server will receive requests destined for the user J.Rosenberg,D.Drew,H.Schulzrinne [Page 19] =0C Internet Draft SIP Firewalls February 22, 2000 inside the firewall/NAT. It sends those requests to the user directly. These requests are intercepted by the firewall/NAT, which passes them to the proxy component. 6.2.3 Finishing Incoming Call Setup The proxy can validate the message, and make sure it is not malicious in nature (for example, ensure it has bodies that are not too long). Once validated, it notes the port numbers and IP addresses in the SDP in the INVITE, but does not open holes in the firewall at this time, nor are address bindings created for the media streams in the case of a NAT. The proxy adds the Record-Route header, which must contain a globally routable IP address for the proxy. Location services are invoked (possibly resulting in next hops with private IP addresses). A NAT will not need to modify any of the fields of the message, as they should all contain globally routable addresses, including the To and Request-URI. The request is then forwarded. When a 200 OK response (or any provisional response with SDP) arrives from inside, the proxy examines the SDP and notes the IP addresses and ports for each media session. If the 200 OK is signed, the proxy/firewall can verify the signature as an additional security mechanism. In the case of a firewall, the 200 OK is forwarded as is normally done. At this point, the proxy opens up holes in the firewall for traffic to and from the ports and addresses in the SDP to enable media in both directions. In the case of NAT, the proxy requests a binding for the private addresses in the SDP in the response. The globally routable addresses obtained from the binding request are placed into the SDP. Note that it is OK for the response to contain Contact or Record-Route headers with private addresses or domain names, so long as the proxy itself is record-routing. Thats because these addresses or names will only be needed by the proxy or other servers from within the private network. When the ACK arrives for the 200 OK, it will pass through the firewall/NAT, and arrive at the proxy. If this ACK contains SDP, the proxy should ensure that the IP address and port have not changed from the INVITE. If they have, new holes in the firewall need to be opened. No special processing is required for the NAT. The ACK is then forwarded. 6.3 Forwarded calls An interesting case, depicted in Figure 5, arises when a user outside J.Rosenberg,D.Drew,H.Schulzrinne [Page 20] =0C Internet Draft SIP Firewalls February 22, 2000 the network (user A), calls a user inside the network (user B), but this call is forwarded to a user outside the network (user C). When the INVITE from A arrives at the proxy, the procedures for incoming calls apply. However, when the INVITE hits the forwarding logic for user B (present in either B's software or in a proxy server within the network) B, and is forwarded out to user C, hitting the firewall/proxy again [3] , different rules apply than the ones outlined in Section 6.1 for outgoing calls. Although this case appears like an outgoing call (INVITE message from within the network to outside), it is not. The difference is that the From field does not correspond to a user within the corporate network. +--------+ | | | | | A | | / | | | / | | | / +--------+ | / | / +------+ +------+ +------+ / | |<---| |<---| |</ | B | |Proxy | |FW/NAT| | |--->| | -->| | +------+ +------+ +------+ | INV C | | | +--------+ | | | | | C | | > | | | | | | +--------+ | | Inside | Outside | _________________________ [3] The astute reader will note that this case appears to be a loop according to RFC2543, although it really isn't. This problem has been identified and a fix has been drafted for the next version of SIP J.Rosenberg,D.Drew,H.Schulzrinne [Page 21] =0C Internet Draft SIP Firewalls February 22, 2000 Figure 5 Specifically, unlike outgoing calls, proxy authentication should not take place for internal service. The call originator is not inside the network. In addition, the proxy does not need to record route, or even be stateful. No holes in the firewall need to be opened for the call, since the media will flow directly between user A and user C (assuming the call is accepted), neither of which is within the enterprise. Neither do address bindings need to be established. It is our recommendation that proxies act statelessly in this configuration. 6.4 Termination A call is terminated with a BYE message. If the BYE comes from the private network, the proxy can use proxy authentication to authenticate the originator of the request if the service is internal. However, the holes in the firewall are not closed yet, and NAT address bindings are not released. If the original INVITE was generated by a host within the private network, and the From field was replaced as it contained a local address, the global address must be replaced in the BYE. This is identical to the procedure for the INVITE itself, and applies to re-INVITES too. When a 200 OK arrives, the proxy closes the holes in the firewall and releases any address bindings in use by the NAT. If the BYE comes from the external network, the NAT must replace the To field if the From field was modified in the original INVITE from the private network. When the 200 OK arrives for the BYE, the proxy can verify the signature on the 200 OK (assuming mutual authentication was used). It is preferable to close the holes in the firewall and release address bindings on the response to the BYE, rather than the BYE itself. In unusual circumstances, the BYE might be rejected and the call remains established. The 200 OK confirms termination of the call. 6.5 Re-INVITEs SIP allows parameters of the session to be changed through re- INVITEs. These re-INVITEs can add new media sessions to the call, in which case new holes need to be opened in the firewall, and new address bindings may need to be created. This process follows the procedure for original call setup. Similarly, re-INVITEs can remove J.Rosenberg,D.Drew,H.Schulzrinne [Page 22] =0C Internet Draft SIP Firewalls February 22, 2000 media sessions from the call, meaning the holes in the firewall need to be closed and bindings released. The procedure for opening or closing holes or establishing bindings for re-INVITEs is identical to opening holes for new INVITEs. In fact, since SIP INVITE messages carry the entire session state, the proxy can simply close all the holes associated with the original INVITE, and re-open ones for this INVITE as if it were the first. For NATs, this will not work. If a media stream is removed as a result of a re-INVITE, that address binding, and that one alone, is released. 6.6 Session Timer As described above, the proxy relies on the SIP BYE message to know when it is safe to close a hole in the firewall or release an address binding in the NAT. However, relying on these messages completely can be problematic for several reasons: o End system crashes may result in calls ending without BYE being sent. o Malicious users may never send BYE in order to attack a proxy. o Poor implementations may not process Record-Route and thus the proxy/firewall may never see a BYE. o Network failures may cause a BYE that is sent to never reach the proxy. The solution to this is for the proxy to make use of the session timer extension for SIP [15]. This will allow the proxy to receive keepalives for the call. If the keepalives stop arriving, the proxy can close the holes in the firewall or release the NAT address bindings. 6.7 Registrations Special consideration must be given to registrations going into, and leaving, the network in the case of internal service. There are legitimate reasons for both to occur. For external service, REGISTER messages are intercepted and then forwarded towards the final destination without any local processing (except to determine that this is a REGISTER message). In the case of a NAT, note that address bindings are never created upon receipt of registrations. Rather, they are triggered when an INVITE arrives that makes use of that registration. J.Rosenberg,D.Drew,H.Schulzrinne [Page 23] =0C Internet Draft SIP Firewalls February 22, 2000 6.7.1 Outgoing Registrations Registrations leave the network (i.e., flow from inside to outside) when a user on the inside registers with some external server. A legitimate application of this is when an employee is travelling on business, and has instructed their SIP server within the corporate network to forward all calls to the main server for the facility the employee is visiting (say, bar.com). This registration does not leave the network. However, in order to receive calls at bar.com, the employee may need to instruct bar.com to forward calls to the specific building he is visiting, bldg12.bar.com. This will require a registration sent to the server at bar.com, indicating bldg12.bar.com in the registration. This REGISTER message is sent externally. An additional case where registrations may leave the network is if a customer has an external SIP forwarding service, perhaps from an organization like acm.org, and they wish to have all calls for them forwarded to work. This requires a registration to be sent from inside the firewall, to the acm.org server, listing their work URL, sip:user@foo.com, in the Contact header. In all cases, the registrations must be such that calls forwarded to the private will always reach the internal proxy that is controlling the firewall or NAT. This results in the following rule: Firewall and NAT controlling proxies should allow SIP registration messages to leave the enterprise. However, if the domain in any of the Contacts is within the corporate network, but the domain of the To field is not, the URLs in the Contact headers MUST contain the firewall/proxy's public IP address or domain name in the host part. If the domain in the To field is within the corporate network, any address, including private IP addresses, are allowed in the Contact headers. Registrations not conforming to this should be rejected with a 600 class response. Like INVITE messages, it is also recommended that proxies perform proxy authentication on outgoing registrations. 6.7.2 Incoming Registrations Incoming registrations allow a user outside the network to establish forwarding state within a proxy on the inside of the network. The scenario arises when an employee of the company is travelling, and is now logged in through some external network. They wish to have calls for them forwarded from work to their new location. This may require a registration to be sent from outside the network, to a registration J.Rosenberg,D.Drew,H.Schulzrinne [Page 24] =0C Internet Draft SIP Firewalls February 22, 2000 server inside the network. We say "may", since if the user is connected externally through a VPN service, the registrations will not pass through the firewall, and will be effectively the same as purely internal registrations. As such, if a corporate intranet has VPN services deployed, and roaming users make use of these services, it is recommended that firewalls disable registrations coming in to the network from the outside. This is accomplished by rejecting, with a 600 response, all registrations which arrive from the external interface. If VPN services are not enabled, registrations should be forwarded or processed when arriving externally if: 1. The registrations are authenticated, and come from a known user of the network, 2. The To field in the registrations corresponds to a valid URL within the corporate enterprise Registrations not meeting these criteria should be rejected. 6.8 Call Cancellation When a call is cancelled, the proxy forwards the CANCEL according to the rules in RFC 2543. The only additional operation to consider is that a provisional response may have been sent for this call, and this provisional response may have opened up holes in the firewall for early media, or may have created address bindings for them. In this case, a cancellation may require the holes to be closed and bindings released for the early media. Before releasing the firewall/NAT resources, the proxy should wait for a certain period for a final 200 OK response to the INVITE which may have crossed the CANCEL on the wire. If none comes, or if a 487 or other non-200 response arrives instead, the holes in the firewall should be closed. 6.9 Additional Messaging SIP defines additional requests, in particular OPTIONS, which do not come into play in the sections above. Extensions have been developed which specify new requests, such as INFO [16]. Since these requests don't alter call or session state, they should be forwarded normally, possibly after proxy authentication. 6.10 Call Flow: Outgoing call The call flow in Figure 6 shows an example of an outgoing call setup through a proxy controlling firewall, in the case of a private J.Rosenberg,D.Drew,H.Schulzrinne [Page 25] =0C Internet Draft SIP Firewalls February 22, 2000 network with internal SIP service. In the diagram, "INV A B" means an INVITE message with SDP whose IP address in the c line is A, and whose port in a single m line is B. Similarly, "200 OK A B" means a 200 OK response with SDP whose IP address in the c line is A, and whose port in a single m line is B. "auth?" is an authorization request to a local authentorization server (such as a RADIUS [17]), or a query to a database server, such as SQL or LDAP. INSIDE Auth Server/ UAC Proxy/FW DB UAS | ------------------------> | auth? | | INV 1.2.3.4. 55 |--------------->| | | |<-------------- | | | <------------------------ | fail | | | 407 | | | | | | | | ------------------------> | | | | ACK | | | | ------------------------> | auth? | | | |--------------->| | | |<-------------- | | | | OK | | INV 1.2.3.4 55 |----------------------------> | = (ringing) | Proxy-Authorization:.. | INV 1.2.3.4 55 | | | Record-Route:.. | | | | | (open)| <--------------------------- | = (answer) | | 200 OK 5.6.7.8 66 | | <-------------------------| | | 200 OK 5.6.7.8 66 | | | | | | ------------------------->| | | ACK | | | | ---------------------------->| | | ACK | | | | | ..........................|..............................| | RTP | | | | | | | | | | <--------------------------- | | <------------------------ | BYE | | BYE | | J.Rosenberg,D.Drew,H.Schulzrinne [Page 26] =0C Internet Draft SIP Firewalls February 22, 2000 | ------------------------> |(close) | | 200 OK |----------------------------> | | | 200 OK | open: Allow UDP, port 55, destination IP 1.2.3.4 into firewall from outside. Allow UDP, port 66, destination IP 5.6.7.8, out of firewall from inside. close: Do not allow UDP, port 55, destination IP 1.2.3.4 into = firewall from outside. Do not allow UDP, port 66, destination IP 5.6.7.8, out of firewall from inside. Figure 6 7 Non-Solutions Two alternate solutions have been proposed for allowing SIP to get through firewalls. Both are primarily aimed at solving the external services configuration. We do not consider these to be viable long term solutions for the problem. They are: 1. Run SIP over port 80, which is used by HTTP [18]. Since SIP is "close" to HTTP, this may fool firewalls into letting SIP requests out of the firewall. 2. Have the user agents open a TCP connection out through the firewall to its SIP server. Call invitations for the user are sent over the open TCP connection. Since many firewalls allow outgoing TCP connections, SIP messaging can flow. The first of these is explicitly frowned upon administrators learn that people are muxing other applications on port 80, and then additional capabilities in firewalls are turned on to block messages based on their content. Furthermore, it is fundamentally a means to bypass administrator policy. It is our belief that the approach for getting SIP through firewalls is to do so cooperatively, where the firewall administrator knows about SIP messaging and explicitly allows it. This is the only solution which can persist long term. Furthermore, although the first solution may succeed in getting SIP out through the firewall, SIP messages won't be forwarded externally into the private network (most firewalls won't let HTTP requests on port 80 into the network to arbitrary hosts). Furthermore, since the media is sent on dynamic UDP ports, the media won't flow through the firewall in all likelihood. J.Rosenberg,D.Drew,H.Schulzrinne [Page 27] =0C Internet Draft SIP Firewalls February 22, 2000 The second solution is similar in concept to the first. It is less antagonistic towards firewall administrators, though. Rather than fooling the administrator, it attempts to fit the service into one of the allowed configurations. It improves upon the first by allowing incoming requests. However, the same problem exists with media streams. Some kind of TCP to UDP translator may be needed in this case. 8 To Do 1. More detail on NAT operation, particularly creation of bindings and detailed message flows. 2. Mention rejecting requests by the proxy that don't contain SDP, as a way to avoid problems associated with chaning the session description format. 9 Author's Addresses Jonathan Rosenberg dynamicsoft 200 Executive Drive Suite 120 West Orange, NJ 07052 email: jdrosen@dynamicsoft.com Dale Drew Director of Security Engineering Level(3) Communications 1450 Infinite Drive Louisville, Colorado, 80027 email: dale.drew@level3.com Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003 email: schulzrinne@cs.columbia.edu 10 Bibliography [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: J.Rosenberg,D.Drew,H.Schulzrinne [Page 28] =0C Internet Draft SIP Firewalls February 22, 2000 session initiation protocol," Request for Comments (Proposed Standard) 2543, Internet Engineering Task Force, Mar. 1999. [2] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a transport protocol for real-time applications," Request for Comments (Proposed Standard) 1889, Internet Engineering Task Force, Jan. 1996. [3] N. Freed, "Behavior of and requirements for internet firewalls," Internet Draft, Internet Engineering Task Force, June 1999. Work in progress. [4] P. Srisuresh and M. Holdrege, "IP network address translator (NAT) terminology and considerations," Request for Comments (Informational) 2663, Internet Engineering Task Force, Aug. 1999. [5] M. Borella, J. Lo, D. Grabelsky, and G. Montenegro, "Realm specific IP: a framework," Internet Draft, Internet Engineering Task Force, Dec. 1999. Work in progress. [6] D. Senie, "NAT friendly application design guidelines," Internet Draft, Internet Engineering Task Force, Feb. 1999. Work in progress. [7] M. Handley and V. Jacobson, "SDP: session description protocol," Request for Comments (Proposed Standard) 2327, Internet Engineering Task Force, Apr. 1998. [8] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, and L. Jones, "SOCKS protocol version 5," Request for Comments (Proposed Standard) 1928, Internet Engineering Task Force, Apr. 1996. [9] G. Nair and H. Schulzrinne, "DHCP option for SIP servers," Internet Draft, Internet Engineering Task Force, Feb. 2000. Work in progress. [10] J. Kempf and J. Rosenberg, "Finding a SIP server with SLP," Internet Draft, Internet Engineering Task Force, Feb. 2000. Work in progress. [11] C. Newman and J. G. Myers, "ACAP -- application configuration access protocol," Request for Comments (Proposed Standard) 2244, Internet Engineering Task Force, Nov. 1997. [12] F. Cuervo, C. Huitema, K. Kelly, B. Rosen, P. Sijben, and E. Zimmerer, "MEGACO protocol proposal," Internet Draft, Internet Engineering Task Force, Mar. 1999. Work in progress. [13] S. Donovan, H. Schulzrinne, J. Rosenberg, M. Cannon, and A. Roach, "SIP 183 session progress message," Internet Draft, Internet J.Rosenberg,D.Drew,H.Schulzrinne [Page 29] =0C Internet Draft SIP Firewalls February 22, 2000 Engineering Task Force, Oct. 1999. Work in progress. [14] J. Rosenberg and H. Schulzrinne, "Reliability of provisional responses in SIP," Internet Draft, Internet Engineering Task Force, Jan. 2000. Work in progress. [15] S. Donovan, "SIP session timer," Internet Draft, Internet Engineering Task Force, Oct. 1999. Work in progress. [16] S. Donovan, "The SIP INFO method," Internet Draft, Internet Engineering Task Force, Jan. 2000. Work in progress. [17] C. Rigney, A. Rubens, W. Simpson, and S. Willens, "Remote authentication dial in user service (RADIUS)," Request for Comments (Proposed Standard) 2138, Internet Engineering Task Force, Apr. 1997. [18] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1," Request for Comments (Draft Standard) 2616, Internet Engineering Task Force, June 1999. J.Rosenberg,D.Drew,H.Schulzrinne [Page 30] =0C --Boundary_(ID_oHcIbii8TF1CP0IU78yAEg)-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Mar 19 12:15:09 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11434 for ; Sun, 19 Mar 2000 12:15:09 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.10C8BD20@standards.nortelnetworks.com>; 19 Mar 2000 12:10:07 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 94842 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 19 Mar 2000 12:08:29 -0500 Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D6475260@standards.nortelnetworks.com>; 19 Mar 2000 12:08:29 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id SAA25888 for ; Sun, 19 Mar 2000 18:12:53 +0100 (MET) 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 SAA08414 for ; Sun, 19 Mar 2000 18:12:45 +0100 (MET) Received: from ericsson.com (arael26m76.ericsson.se [130.100.249.76]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id SAA20224 for ; Sun, 19 Mar 2000 18:12:44 +0100 (MET) X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <1BAFEBDF4429D311BA4C0008C70DB9D2809542@MCHH245E> <38D22E7E.98C229F1@lucent.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <38D50ACA.DB1EC849@ericsson.com> Date: Sun, 19 Mar 2000 18:13:47 +0100 Reply-To: Stephen Terrill Sender: "Media Gateway Control (megaco)" From: Stephen Terrill Organization: L.M. Ericsson Subject: Re: "IP/IP" Media gateways? To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hi, Wouldn´t whether the MG is acting as a NAT or not would depend open whether the commucatation between the MGCs tries to iniatate a connection from the left most MG or the right most MG, or if it is such that the MGC communication requests the bearer to be established on a link-by-link bases (ie BICC). In the latter case, then I would assume that it would H.248 which just happens to do packet-to-packet. Regards, ..//Steve John Segers wrote: > Christian, > > The box you labeled "IP/IP MG" is, according to your description a NAT > device. I believe that ETSI TIPHON has started requirements work on > controlling NATs in the media path of calls. Maybe megaco can meet the > requirements for this IP/IP GW application. > > Cheers, > > John > > Ruppelt Christian wrote: > > > > maybe I missed the discussion... > > > > Does H.248/Megaco provide a solution for "IP/IP" Media gateways? > > > > Motivation: > > > > IP Domain A IP Domain B > > MGC--(e.g. BICC)----MGC---------(e.g.BICC---MGC----------MGC > > / / / > > > > (H.248) (H.248 ???) (H.248 ???) > > \ \ \ > > MG--IP Network A---"IP/IP MG"---Public---"IP/IP MG"----IP NetB > > Internet > > > > IP real time streams cross borders between different administrative > > domains, (e.g.VoIP VPNs embedded in Telco IP backbones,enterprise > > intranets) > > The address of MG in Domain A is not known in the Domain B and > > vice versa. > > A solution for IPv4 and it's restricted address space is required. > > > > For a Call from Domain A into Domain B on a per call basis the MGC > > has to select the ports on the "IP/IP MG" > > > > Christian > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 306 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Mar 20 01:23:30 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10861 for ; Mon, 20 Mar 2000 01:23:30 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.388AEC20@standards.nortelnetworks.com>; Mon, 20 Mar 2000 1:18:38 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 95165 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 20 Mar 2000 01:16:42 -0500 Received: from ish7.ericsson.com.au (203.61.155.111) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8D4ED250@standards.nortelnetworks.com>; Mon, 20 Mar 2000 1:06:41 -0500 Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.1) with ESMTP id RAA18446; Mon, 20 Mar 2000 17:09:38 +1100 (EST) Received: from mcsi00.epa.ericsson.se (mcsi00 [146.11.8.201]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id RAA19366; Mon, 20 Mar 2000 17:10:18 +1100 (EST) Received: from ericsson.com (mcdh183.epa.ericsson.se [146.11.81.183]) by mcsi00.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id RAA17783; Mon, 20 Mar 2000 17:09:32 +1100 (EST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4.2.2.20000313172117.00a66de0@dogwood.cisco.com> <38CE4D0F.A514434F@americasm01.nt.com> <38D1AA75.843C39D6@cisco.com> <4.3.1.2.20000317081943.00b80940@dogwood.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38D5C0A5.8927A2F8@ericsson.com> Date: Mon, 20 Mar 2000 17:09:41 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Descriptor processing order X-To: Chip Sharp To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Chip, I completely agree with what you say. Command's should either succeed or fail. What I was concerned about is something like playing a signal from a signal descriptor and then the MG changes a property in a local descriptor which fails. This is all done in a modify command. The command fails because of the error. Hopefully the MG doesn't try to return the state to what it was before the command. ie. Once a signal is played you can't get it back. It was this clarification about what the MG does that I was looking for. Cheers, Christian Chip Sharp wrote: > > I'll leave it up to the experts, but I imagine it would be similar to a > Q.931 SETUP message. > > If the switch executes one Information Element and the next one fails, the > switch treats the entire SETUP message as in error. > > I believe there should be atomicity at some level. If we go one level > deeper, we could look at what happens within a descriptor in the ordering > of parameters. If one parameter succeeds and the next fails, the MG has to > recover. I tend to think that a command should be atomic. It either > succeeds or fails. I think independence of execution of descriptors would > make it even more difficult than it already is for the MGC and MG to remain > in synch (and sane). > > Chip > > At 03:39 PM 3/17/00 +1100, Christian Groves wrote: > >G'Day Abdallah, > > > >I can buy saying that descriptors are processed in order but what do we > >gain by adding "All commands are atomic operations, either succeed or > >fail as a whole". What does this really mean?? > >If one decriptor is executed and the next descriptor fails what does the > >MG do? > > > >Christian > > > >Flemming Andreasen wrote: > > > > > > Sounds good to me. > > > > > > -- Flemming > > > > > > Abdallah Rayhan wrote: > > > > > > > I believe there is an agreement that commands are atomic, either > > > > succeed or fail and no partial commands. but I agree with you that > > > > there is no text, up to my knowledge, saying that descriptors are > > > > attempted in order. The closest we get to this is in Section 8, > > > > "Transactions guarantee ordered Command processing. That is, Commands > > > > within a Transaction are executed sequentially. Ordering of > > Transactions is > > > > NOT guaranteed - transactions may be executed in any order, or > > > > simultaneously." > > > > > > > > I propose adding the following sentence to the above paragraph, > > > > " All commands are atomic operations, either succeed or fail as a whole, > > > > and descriptors within commands are processed in sequence of their > > > > order." > > > > > > > > Abdallah Rayhan > > > > > > > > Chip Sharp wrote: > > > > > > > > > Due to a previous question on event handling, I went through the > > output of > > > > > SG16 (TD37) looking for text on the ordering of processing of > > descriptors. > > > > > > > > > > However, I could find no text in the document that describes in > > what order > > > > > a MG or MGC should process descriptors. I was specifically > > wondering if > > > > > the TerminationStateDescriptor was processed before the > > > > > EventsDescriptor. This has implications in that the order of > > processing > > > > > the value of the EventBufferControl parameter in the > > > > > TerminationStateDescriptor and the EventsDescriptor will affect how > > events > > > > > in the EventBuffer are processed. > > > > > > > > > > If TerminationStateDescriptor is processed first and > > EventBufferControl=Off > > > > > (previous LockStep), then all events are discarded. If > > EventsDescriptor is > > > > > processed first then at least one more event will be reported > > before the > > > > > EventBuffer is flushed (ignoring the previous discussion as to > > whether this > > > > > is desirable or not). > > > > > > > > > > It seems there may be any number of conditions like this that will > > depend > > > > > on ordering of processing of descriptors in the command. > > > > > > > > > > Shouldn't there be some basic text in the spec that either > > specifies that > > > > > the receiver of a command should process the descriptors in the order > > > > > received or that the receiver can process them in any order desired? I > > > > > prefer the former. The latter seems a little indeterminate. > > > > > > > > > > If there is already text of this nature in the document, please > > educate me > > > > > as to its location. > > > > > > > > > > Thanks, > > > > > Chip > > > > > Support NetAid! http://www.netaid.org > > > > > -------------------------------------------------- > > > > > Chip Sharp Consulting Engineering > > > > > Cisco Systems Telco Bio-region > > > > > Reality - Love it or Leave it. > > > > > -------------------------------------------------- > > Support NetAid! http://www.netaid.org > -------------------------------------------------- > Chip Sharp Consulting Engineering > Cisco Systems Telco Bio-region > Reality - Love it or Leave it. > -------------------------------------------------- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Mar 20 07:25:07 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00624 for ; Mon, 20 Mar 2000 07:25:06 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B13A6330@standards.nortelnetworks.com>; Mon, 20 Mar 2000 7:19:55 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 95378 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 20 Mar 2000 07:18:04 -0500 Received: from relay.mail.pipex.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6EDA3330@standards.nortelnetworks.com>; Mon, 20 Mar 2000 7:18:04 -0500 Received: (qmail 21684 invoked from network); 20 Mar 2000 12:22:31 -0000 Received: from gatekeeper.sgcs.co.uk (HELO bevx03.gpt.co.uk) (194.129.217.113) by iprelay.mail.pipex.net with SMTP; 20 Mar 2000 12:22:31 -0000 Received: from CONVERSION-DAEMON by siemenscomms.co.uk (PMDF V5.1-12 #D3115) id <01JN97QHV33K90PX0F@siemenscomms.co.uk>; Mon, 20 Mar 2000 12:19:46 GMT Received: from beex01.sgcs.co.uk ([19.0.53.101]) by siemenscomms.co.uk (PMDF V5.1-12 #D3115) with ESMTP id <01JN97QD6KCG90Q7P9@siemenscomms.co.uk>; Mon, 20 Mar 2000 12:19:40 +0000 (GMT) Received: by beex01.sgcs.co.uk with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Mar 2000 12:19:11 +0000 Content-return: allowed MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Message-ID: <5AC7D3F55147D311AA1700A0C99583ED2C369F@beex03.sgcs.co.uk> Date: Mon, 20 Mar 2000 12:19:10 +0000 Reply-To: "Drage, Keith" Sender: "Media Gateway Control (megaco)" Comments: *********************************************** Comments: * Our domain is now siemenscomms.co.uk * Comments: * Please update your address book accordingly * Comments: *********************************************** From: "Drage, Keith" Subject: Re: Comments on MEGACO protocol X-To: "jsegers@lucent.com" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7BIT I have no real view on which way this should be documented. We do have the potential for a major admin problem here. The order of the SG meetings on 15th June is first Study Group 4, then Study Group 16, then Study Group 11. Q.2941.3 will be decided (we hope) at 14:30 on Thursday 15th June. H.248 will be decided (we hope) at approx. 11:00 on Thursday 15th June. These Study Groups are sequential rather than in parallel, and in any case no editing will be allowed on the floor of the meeting. One single administration could create total chaos and confusion by allowing H.248 to be decided, and then objecting to Q.2941.3 later in the day. Note that Q.2941.3 is dependent on the existence of Q.1900, so the objection could be that far back. Therefore I think the safest option is to allow all values of GIT. The length becomes a maximum of 29 octets (33 octets as specified in Q.2941.1 clause 8.2.1 less 4 octets header) - the coding starts at octet 5 onwards (I assume). The reference should then be to Q.2941.1 as extended by subsequent recommendations in the Q.2941.x series. Keith Drage > --------------------------------------------------------------- > Keith Drage (keith.drage@siemenscomms.co.uk) > Siemens Communications Limited, > Technology Drive, Beeston, Nottingham NG9 1LA, UK > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > --------------------------------------------------------------- > Internet communications are not secure and therefore Siemens > Communications Limited does not accept legal responsibility for the > contents of this message. Any views or opinions presented are solely > those of the author and do not necessarily represent those of Siemens > Communications Limited unless otherwise specifically stated. > > -----Original Message----- > From: John Segers [mailto:jsegers@LUCENT.COM] > Sent: Wednesday, March 15, 2000 3:11 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Comments on MEGACO protocol > > > Christian, > > I believe it makes sense when it is used for binding reference. If we > only use octet 5 and above, and only use the GIT parameter for this > specific case, we should rethink the name of the parameter. Using GIT > with a reference to Q.2941.1 will undoubtedly lead to confusion. > > John > > Christian Groves wrote: > > > > G'Day Keith and John, > > > > Regarding 6 the intention was to use this as a binding reference > > (BNCid). Annex C should refer to octet 5 and above. For the > BNCid the > > length as per the GIT would be 6 octets. Make sense? > > > > Cheers, Christian > > > > John Segers wrote: > > > > > > Keith, > > > > > > Most of the changes you request are ok. There's a couple > that I don't > > > know about: > > > - (Re. 3) I thought that references to ITU Rec. have to > be specific > > > (i.e., including a date). I asked Glen, and he's not sure either. > > > We'll check. > > > - (Re. 5) What headers are missing according to you? The > current ASN.1 > > > starts with "MEDIA-GATEWAY-CONTROL DEFINITIONS AUTOMATIC > TAGS::=". I > > > checked the syntax with the OSS tools and didn't find a problem. > > > - (Re. 6) I believe this was brought in through MSF and I never > > > checked. Having looked up Q.2941.1 now, I agree that 4 octets is > > > restrictive. > > > > > > John > > > > > > "Drage, Keith" wrote: > > > > > > > > Attached please find a number of editorial comments on > the Geneva output > > > > document, which we also understand is identical to the > MEGACO last call > > > > document. These points are not intended to be > controversial. In the event > > > > that discussion is required to resolve such a comment, > then we will withdraw > > > > the comment in order to allow the document to proceed. > > > > > > > > 1) Abbreviations. "BRI" is never used and > therefore should be removed > > > > from the list of abbreviations. > > > > > > > > 2) References. Q.724 is never used and should be removed. > > > > > > > > 3) References and annex C. Where a reference is > only used in annex C, > > > > we believe in general in most cases these should be > undated (i.e. the latest > > > > version of the referenced document applies). This in > particular applies to > > > > Q.931, Q. 2931, Q.763 where ITU-T SG11 have no > intention of changing > > > > codepoints to different values, but do reserve the > right to add new values. > > > > Surely the whole ethos of annex C is that new values do > get automatically > > > > incorporated. > > > > > > > > 4) References (and annex C if comment 3 not > accepted). Some of the > > > > dates are incorrect. Q.761-4 have a date of December > 1999 as that was > > > > decided last year. Q.2931 should reflect the date of > the latest amendment > > > > (4) which we believe is also December 1999. > > > > > > > > 5) Annex A. We could not find the module header, > or an exports > > > > statement, for the ASN.1. The module header is > mandatory parts of the ASN.1, > > > > and gives that module an object identifier, which is > needed for inport to > > > > anything else. > > > > > > > > 6) Annex C, C.8, generic identifier transport. We > are not sure how you > > > > fit this into four octets. Is there some subset of the > generic identifier > > > > transport information element that is being used? > Various codings of this > > > > information element get very, very long. > > > > > > > > 7) Annex C, C.9, ITC has a reference to a note 2, > which is not in the > > > > table. Is this a spurious inport from the referenced > standard? If so, we > > > > believe it can be deleted. > > > > > > > > 8) Annex C, C.9. References to Q.931 need to > identify that the > > > > references are to the encoding in the Bearer capability > information element, > > > > and not to the Low layer information element. The > latter has identical > > > > fields with the same code values, but has a more > extensive range of values > > > > assigned. This is because some values (particularly at > layer 3) are only > > > > defined for end user to addressed end user usage. I > believe in H.248 only > > > > the more restricted list in the Bearer capability > information element would > > > > be valid. > > > > > > > > Keith Drage > > > > > > > > > > --------------------------------------------------------------- > > > > > Keith Drage (keith.drage@siemenscomms.co.uk) > > > > > Siemens Communications Limited, > > > > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > > > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > > > > > --------------------------------------------------------------- > > > > > Internet communications are not secure and therefore Siemens > > > > > Communications Limited does not accept legal > responsibility for the > > > > > contents of this message. Any views or opinions > presented are solely those > > > > > of the author and do not necessarily represent those > of Siemens > > > > > Communications Limited unless otherwise specifically stated. > > > > > > > > > > > > > > > > -- > > > John Segers email: > jsegers@lucent.com > > > Lucent Technologies > Room HE 306 > > > Dept. Forward Looking Work phone: > +31 35 687 4724 > > > P.O. Box 18, 1270 AA Huizen fax: > +31 35 687 5954 > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 306 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Mar 20 07:25:07 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00631 for ; Mon, 20 Mar 2000 07:25:07 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B1A33720@standards.nortelnetworks.com>; Mon, 20 Mar 2000 7:19:56 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 95383 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 20 Mar 2000 07:18:06 -0500 Received: from relay.mail.pipex.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6FDBC4B0@standards.nortelnetworks.com>; Mon, 20 Mar 2000 7:18:06 -0500 Received: (qmail 21697 invoked from network); 20 Mar 2000 12:22:33 -0000 Received: from gatekeeper.sgcs.co.uk (HELO bevx03.gpt.co.uk) (194.129.217.113) by iprelay.mail.pipex.net with SMTP; 20 Mar 2000 12:22:33 -0000 Received: from CONVERSION-DAEMON by siemenscomms.co.uk (PMDF V5.1-12 #D3115) id <01JN97SRANCW90Q9ZO@siemenscomms.co.uk>; Mon, 20 Mar 2000 12:21:35 GMT Received: from beex01.sgcs.co.uk ([19.0.53.101]) by siemenscomms.co.uk (PMDF V5.1-12 #D3115) with ESMTP id <01JN97SO3Z9S90P095@siemenscomms.co.uk>; Mon, 20 Mar 2000 12:21:30 +0000 (GMT) Received: by beex01.sgcs.co.uk with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Mar 2000 12:21:07 +0000 Content-return: allowed MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Message-ID: <5AC7D3F55147D311AA1700A0C99583ED2C36A0@beex03.sgcs.co.uk> Date: Mon, 20 Mar 2000 12:21:06 +0000 Reply-To: "Drage, Keith" Sender: "Media Gateway Control (megaco)" Comments: *********************************************** Comments: * Our domain is now siemenscomms.co.uk * Comments: * Please update your address book accordingly * Comments: *********************************************** From: "Drage, Keith" Subject: Re: Comments on MEGACO protocol X-To: "jsegers@lucent.com" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7BIT See below: Keith Drage > --------------------------------------------------------------- > Keith Drage (keith.drage@siemenscomms.co.uk) > Siemens Communications Limited, > Technology Drive, Beeston, Nottingham NG9 1LA, UK > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > --------------------------------------------------------------- > Internet communications are not secure and therefore Siemens > Communications Limited does not accept legal responsibility for the > contents of this message. Any views or opinions presented are solely > those of the author and do not necessarily represent those of Siemens > Communications Limited unless otherwise specifically stated. > > -----Original Message----- > From: John Segers [mailto:jsegers@LUCENT.COM] > Sent: Monday, March 13, 2000 7:44 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Comments on MEGACO protocol > > > Keith, > > Most of the changes you request are ok. There's a couple that I don't > know about: > - (Re. 3) I thought that references to ITU Rec. have to be specific > (i.e., including a date). I asked Glen, and he's not sure either. > We'll check. Recommendation A.3 keeps changing, but in the version I checked, while a date is certainly allowed, none of the words told me it had to be there. (I also found no words providing specifically for their omission.) We have certainly used undated references in SG11 in the past. ISO and ETSI rules (which the ITU-T rules have been brought closer to) certainly allow undated references and specifically provide for them. > - (Re. 5) What headers are missing according to you? The > current ASN.1 > starts with "MEDIA-GATEWAY-CONTROL DEFINITIONS AUTOMATIC TAGS::=". I > checked the syntax with the OSS tools and didn't find a problem. I have rechecked the header against the new ASN.1, and syntactically the current stuff is OK. Semantically also, according to the new ASN.1 definition, I understand that omitting the keyword, it exports everything, which I had not understood before. All therefore OK here. The header is however missing an optional assigned object identifier (construct DefinitiveIdentifier) and I believe this is essential when trying to import material to other ASN.1 moduled. I believe that it would be useful to add an object identifier to the header. The question is, which module identifier. For H.248 a suitable object identifier would be: itu-t recommendation h 248 media-gateway-control(0) Would this also be acceptable for the IETF version? > - (Re. 6) I believe this was brought in through MSF and I never > checked. Having looked up Q.2941.1 now, I agree that 4 octets is > restrictive. See comments on a separate email. > > John > > "Drage, Keith" wrote: > > > > Attached please find a number of editorial comments on the > Geneva output > > document, which we also understand is identical to the > MEGACO last call > > document. These points are not intended to be > controversial. In the event > > that discussion is required to resolve such a comment, then > we will withdraw > > the comment in order to allow the document to proceed. > > > > 1) Abbreviations. "BRI" is never used and therefore > should be removed > > from the list of abbreviations. > > > > 2) References. Q.724 is never used and should be removed. > > > > 3) References and annex C. Where a reference is only > used in annex C, > > we believe in general in most cases these should be undated > (i.e. the latest > > version of the referenced document applies). This in > particular applies to > > Q.931, Q. 2931, Q.763 where ITU-T SG11 have no intention of changing > > codepoints to different values, but do reserve the right to > add new values. > > Surely the whole ethos of annex C is that new values do get > automatically > > incorporated. > > > > 4) References (and annex C if comment 3 not accepted). > Some of the > > dates are incorrect. Q.761-4 have a date of December 1999 > as that was > > decided last year. Q.2931 should reflect the date of the > latest amendment > > (4) which we believe is also December 1999. > > > > 5) Annex A. We could not find the module header, or an exports > > statement, for the ASN.1. The module header is mandatory > parts of the ASN.1, > > and gives that module an object identifier, which is needed > for inport to > > anything else. > > > > 6) Annex C, C.8, generic identifier transport. We are > not sure how you > > fit this into four octets. Is there some subset of the > generic identifier > > transport information element that is being used? Various > codings of this > > information element get very, very long. > > > > 7) Annex C, C.9, ITC has a reference to a note 2, > which is not in the > > table. Is this a spurious inport from the referenced > standard? If so, we > > believe it can be deleted. > > > > 8) Annex C, C.9. References to Q.931 need to identify that the > > references are to the encoding in the Bearer capability > information element, > > and not to the Low layer information element. The latter > has identical > > fields with the same code values, but has a more extensive > range of values > > assigned. This is because some values (particularly at > layer 3) are only > > defined for end user to addressed end user usage. I believe > in H.248 only > > the more restricted list in the Bearer capability > information element would > > be valid. > > > > Keith Drage > > > > > --------------------------------------------------------------- > > > Keith Drage (keith.drage@siemenscomms.co.uk) > > > Siemens Communications Limited, > > > Technology Drive, Beeston, Nottingham NG9 1LA, UK > > > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > > > --------------------------------------------------------------- > > > Internet communications are not secure and therefore Siemens > > > Communications Limited does not accept legal > responsibility for the > > > contents of this message. Any views or opinions presented > are solely those > > > of the author and do not necessarily represent those of Siemens > > > Communications Limited unless otherwise specifically stated. > > > > > > > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 306 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > > --------------------------------------------------------------- > Keith Drage (keith.drage@siemenscomms.co.uk) > Siemens Communications Limited, > Technology Drive, Beeston, Nottingham NG9 1LA, UK > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > --------------------------------------------------------------- > Internet communications are not secure and therefore Siemens > Communications Limited does not accept legal responsibility for the > contents of this message. Any views or opinions presented are solely those > of the author and do not necessarily represent those of Siemens > Communications Limited unless otherwise specifically stated. > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Mar 20 09:21:23 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20036 for ; Mon, 20 Mar 2000 09:21:23 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EE537580@standards.nortelnetworks.com>; Mon, 20 Mar 2000 9:16:10 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 95549 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 20 Mar 2000 09:14:22 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.47D99EB0@standards.nortelnetworks.com>; Mon, 20 Mar 2000 9:04:21 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id JAA22709; Mon, 20 Mar 2000 09:08:47 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id JAA23797; Mon, 20 Mar 2000 09:08:44 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Mar 2000 09:04:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF208B0B@whq-msgusr-02.fore.com> Date: Mon, 20 Mar 2000 09:08:07 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Descriptor processing order X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM I also agree commands should be atomic. We aren't forgetting that the problem of descriptor order isn't related to failure, right? Brian > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > Sent: Monday, March 20, 2000 1:10 AM > To: MEGACO@standards.nortelnetworks.com > Subject: Re: Descriptor processing order > > > G'Day Chip, > > I completely agree with what you say. Command's should either > succeed or > fail. What I was concerned about is something like playing a > signal from > a signal descriptor and then the MG changes a property in a local > descriptor which fails. This is all done in a modify command. The > command fails because of the error. > > Hopefully the MG doesn't try to return the state to what it was before > the command. ie. Once a signal is played you can't get it back. It was > this clarification about what the MG does that I was looking for. > > Cheers, Christian > > Chip Sharp wrote: > > > > I'll leave it up to the experts, but I imagine it would be > similar to a > > Q.931 SETUP message. > > > > If the switch executes one Information Element and the next > one fails, the > > switch treats the entire SETUP message as in error. > > > > I believe there should be atomicity at some level. If we > go one level > > deeper, we could look at what happens within a descriptor > in the ordering > > of parameters. If one parameter succeeds and the next > fails, the MG has to > > recover. I tend to think that a command should be atomic. > It either > > succeeds or fails. I think independence of execution of > descriptors would > > make it even more difficult than it already is for the MGC > and MG to remain > > in synch (and sane). > > > > Chip > > > > At 03:39 PM 3/17/00 +1100, Christian Groves wrote: > > >G'Day Abdallah, > > > > > >I can buy saying that descriptors are processed in order > but what do we > > >gain by adding "All commands are atomic operations, either > succeed or > > >fail as a whole". What does this really mean?? > > >If one decriptor is executed and the next descriptor fails > what does the > > >MG do? > > > > > >Christian > > > > > >Flemming Andreasen wrote: > > > > > > > > Sounds good to me. > > > > > > > > -- Flemming > > > > > > > > Abdallah Rayhan wrote: > > > > > > > > > I believe there is an agreement that commands are > atomic, either > > > > > succeed or fail and no partial commands. but I agree > with you that > > > > > there is no text, up to my knowledge, saying that > descriptors are > > > > > attempted in order. The closest we get to this is in > Section 8, > > > > > "Transactions guarantee ordered Command processing. > That is, Commands > > > > > within a Transaction are executed sequentially. Ordering of > > > Transactions is > > > > > NOT guaranteed - transactions may be executed in any order, or > > > > > simultaneously." > > > > > > > > > > I propose adding the following sentence to the above > paragraph, > > > > > " All commands are atomic operations, either succeed > or fail as a whole, > > > > > and descriptors within commands are processed in > sequence of their > > > > > order." > > > > > > > > > > Abdallah Rayhan > > > > > > > > > > Chip Sharp wrote: > > > > > > > > > > > Due to a previous question on event handling, I > went through the > > > output of > > > > > > SG16 (TD37) looking for text on the ordering of > processing of > > > descriptors. > > > > > > > > > > > > However, I could find no text in the document that > describes in > > > what order > > > > > > a MG or MGC should process descriptors. I was specifically > > > wondering if > > > > > > the TerminationStateDescriptor was processed before the > > > > > > EventsDescriptor. This has implications in that > the order of > > > processing > > > > > > the value of the EventBufferControl parameter in the > > > > > > TerminationStateDescriptor and the EventsDescriptor > will affect how > > > events > > > > > > in the EventBuffer are processed. > > > > > > > > > > > > If TerminationStateDescriptor is processed first and > > > EventBufferControl=Off > > > > > > (previous LockStep), then all events are discarded. If > > > EventsDescriptor is > > > > > > processed first then at least one more event will > be reported > > > before the > > > > > > EventBuffer is flushed (ignoring the previous > discussion as to > > > whether this > > > > > > is desirable or not). > > > > > > > > > > > > It seems there may be any number of conditions like > this that will > > > depend > > > > > > on ordering of processing of descriptors in the command. > > > > > > > > > > > > Shouldn't there be some basic text in the spec that either > > > specifies that > > > > > > the receiver of a command should process the > descriptors in the order > > > > > > received or that the receiver can process them in > any order desired? I > > > > > > prefer the former. The latter seems a little indeterminate. > > > > > > > > > > > > If there is already text of this nature in the > document, please > > > educate me > > > > > > as to its location. > > > > > > > > > > > > Thanks, > > > > > > Chip > > > > > > Support NetAid! http://www.netaid.org > > > > > > -------------------------------------------------- > > > > > > Chip Sharp Consulting Engineering > > > > > > Cisco Systems Telco Bio-region > > > > > > Reality - Love it or Leave it. > > > > > > -------------------------------------------------- > > > > Support NetAid! http://www.netaid.org > > -------------------------------------------------- > > Chip Sharp Consulting Engineering > > Cisco Systems Telco Bio-region > > Reality - Love it or Leave it. > > -------------------------------------------------- > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Mar 20 10:32:31 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21347 for ; Mon, 20 Mar 2000 10:32:30 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E039F280@standards.nortelnetworks.com>; Mon, 20 Mar 2000 10:27:21 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 95685 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 20 Mar 2000 10:25:56 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AD1D8920@standards.nortelnetworks.com>; Mon, 20 Mar 2000 10:25:55 -0500 Received: from zcard00n.ca.nortel.com (actually zcard00n) by smtprch1.nortel.com; Mon, 20 Mar 2000 09:18:10 -0600 Received: from zcard00f.ca.nortel.com ([47.129.30.8]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HGK873ST; Mon, 20 Mar 2000 10:17:52 -0500 Received: from americasm01.nt.com (wcars052.ca.nortel.com [47.128.210.104]) by zcard00f.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GWMNT6NZ; Mon, 20 Mar 2000 10:17:50 -0500 X-Mailer: Mozilla 4.6 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <38D248B9.CA3F8D92@aztek-eng.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38D64197.6FCF4DED@americasm01.nt.com> Date: Mon, 20 Mar 2000 10:19:51 -0500 Reply-To: Abdallah Rayhan Sender: "Media Gateway Control (megaco)" From: Abdallah Rayhan Organization: Nortel Networks Subject: Re: ABNF for alternativeValue X-To: Jo Friedman To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Jo, You are right. I hate to exclude DOT from VALUE as it might have a negative effect on packages or some intended use of VALUE. Something else you brought up in which 1..2 is a legal VALUE, hence things like 1..2..3..4 is parsable as a legal alternativeValue. I would say that is oversight from my part when I crafted those roles. An easy way out of this miss is to change the horizontal DOT DOT to vertical one ":" -), e.g., 1:2 instead of 1..2. Range is expressed by ":" and ".." is a valid VALUE but package dependent. While this would still allow things like 1..2:3..4, semantics should play a role here not just the syntax, e.g. if the package does not allow this value then it should be rejected as an error. Proposal: alternativeValue = ( VALUE / LSBRKT VALUE *(COMMA VALUE) RSBRKT / LSBRKT VALUE COLON VALUE RSBRKT ) Abdallah Jo Friedman wrote: > In the MEGACO text-encoding production > > alternativeValue = ( VALUE / LSBRKT VALUE *(COMMA VALUE) > RSBRKT / > LSBRKT VALUE DOT DOT VALUE RSBRKT ) > > The following is a legal VALUE > 1..2 > > because a VALUE can contain dots (the final SafeChar is '.'). > > So unfortunately, there are two ways to parse > [1..2] > > it could be one VALUE (the first required VALUE) in > LSBRKT VALUE *(COMMA VALUE) RSBRKT > > or it could be two values separated by two dots as in > LSBRKT VALUE DOT DOT VALUE RSBRKT > > Any thoughts on how to resolve this? > Jo From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Mar 20 21:37:42 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05157 for ; Mon, 20 Mar 2000 21:37:41 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D28A6630@standards.nortelnetworks.com>; Mon, 20 Mar 2000 21:32:41 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 96623 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 20 Mar 2000 21:31:33 -0500 Received: from smtprich.nortel.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A9CDEEB0@standards.nortelnetworks.com>; Mon, 20 Mar 2000 21:31:33 -0500 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprich.nortel.com; Mon, 20 Mar 2000 20:36:29 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Mar 2000 20:35:33 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF92DE.2168BB10" X-Orig: Message-ID: Date: Mon, 20 Mar 2000 20:35:24 -0600 Reply-To: Nancy-M Greene Sender: "Media Gateway Control (megaco)" From: Nancy-M Greene Subject: V16 review - Editorial comments 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_01BF92DE.2168BB10 Content-Type: text/plain; charset="iso-8859-1" Brian, John, I believe each of the following is an editorial change to V16. You have both seen most of these already, and commented on them - I am posting them to the megaco list this time, with the proposed resolutions. Please comment! 1- Section 7.1.1 Specifying Parameters Issue: para. starting with "Unspecified mandatory parameters (i.e. mandatory parameters not specified in a descriptor) result in the command responder retaining the previous value for that parameter." Comment: It seems that this section applies only to mandatory fields in Local and Remote descriptors (see section 7.1.8). For example, when a mandatory parameter is unspecified in the Local descriptor, then it retains the value it already has. But, a mandatory parameter in a ServiceChange HAS to be there I would think. For example, the ServiceChangeMethod descriptor is mandatory, and must always be present. Proposal: Preface the quoted sentence in 7.1.1 with "For Local and Remote Descriptors, unspecified mandatory parameters (i.e. mandatory parameters not specified in a descriptor) result in the ...." 2- Section 7.1.6 Stream Descriptor Issue: last sentence of first para, "A stream is deleted by setting empty Local and Remote descriptors for the stream with ReserveGroup and ReserveValue in LocalControl set to "false" on all terminations in the context that previously supported that stream." Comment: We don't have false or true in the ABNF, only "ON/OFF". The text uses both true/false, and on/off. Proposal: Make no changes to the text. Just add this comment: "ON = true, and OFF = false" to the ABNF. 3- Section 7.1.7 LocalControl Descriptor - ReserveGroup/ReserveValue Issue: There is no explanation as to what ReserveValue and ReserveGroup mean. Proposal: Add text something like the following: "In order to state that one session description is to be selected out of a list, ReserveGroup is set to "false". If resources for all session descriptions are to be reserved, ReserveGroup is set to "true". In order to state that a parameter with a list of values, e.g. multiple rtp payload types, requires one value is to be selected from the list, ReserveValue is set to "false". If resources for all values are to be reserved, ReserveValue is set to "true". In other words, overspecifying by giving a list of values can happen independently at the session description level and at the parameter level. " 4- Section 7.1.9 Events Descriptor - eventDM Issue: eventDM is not mentioned in this section while it is part of the eventsDescriptor syntax. Proposal: Add this sentence: "If a digit map is required in the EventsDescriptor, EventDM is used to carry either the name or the value of the digit map. See section 7.1.14." 5- Section 7.1.11 Signals Descriptor Issue: setting of the signal list type Proposal: Add the following to section 7.1.11: * on/off in signal list -> it must be the last element, and signal list type must be on/off * timeout in signal list (and NO on/off signals in the list) -> signal list type must be timeout * only brief signals in signal list -> signal list type defaults to brief. 6- Section 7.1.12 Audit Descriptor, and also auditItem in the ABNF Issue: the last entry in the table is "EventBuffer". auditItem in the ABNF does not qualify it either which is incorrect. Proposal: Change "EventBuffer" to "EventBuffer Descriptor" in both section 7.1.12 and in the ABNF. 7- Section 7.1.13 ServiceChangeDescriptor Issue: Extension is not part of the enumeration Comment: Is ServiceChangeDescriptor supposed to be extendable or not? The ABNF still has an extension parameter in it. 8- Section 7.1.18 Topology Descriptor Issue: para starting with "(T1,T2, bothway) means that .... loopbacks are created by setting the TerminationMode." Comment: We don't have TerminationMode any more. Proposal: change it to read: "...loopbacks are created by setting the StreamMode property to LoopBack in the LocalControlDescriptor." 9- 7.2.5 Audit Value Issue "W-" and "O-" Comment: Text does not describe that wildcarded response is qualified by "W-". Also, no text explaining that optional commands are qualified by "O-". Proposal: in section 7.2.5, add the following: "The wildcard response option (see section 6.2.2) is particularly useful to limit the size of a n audit value command which uses a wildcard terminationId. In ASN.1 encoding (Annex A), the flag "wildcardReturn" is set on a command, and in ABNF (Annex B), the command is qualified by the "W-" option." Also, in section 8, add the following: "In ASN.1 encoding, the flag "optional" is set on a command, and in the ABNF, the command is qualified with the "O-" option." 10- Section 7.2.6 AuditCapabilities Issue: AuditCapability API Comment: same as in 9-Section 7.2.5 Proposal: Add same sentences as above, to this section. 11- Section 7.2.6 AuditCapabilities - DigitMap and Packages Issue: DigitMap and Packages in the ABNF Comment: The ABNF allows DigitMap and Packages in the return of AuditCapability. The text says no. Need to add a comment in the ABNF that explains this. Proposal: Add the following comment to the ABNF: "DigitMap and Packages are not permitted to be part of AuditCapabilities" 12- ANNEX B: signalListParm Issue: signalListParm = signalRequest Comment: This is redundant. Proposal: in the ABNF, signalRequest should replace signalListParm in signalList. 13- ANNEX B:digitMapValue Issue: digitMapDescriptor = DigitMapToken EQUAL digitMapName ( LBRKT digitMapValue RBRKT ) Comment: error with the round brackets Proposal: it should be digitMapDescriptor = DigitMapToken EQUAL digitMapName [ LBRKT digitMapValue RBRKT ] 14- ANNEX B: version token Issue: VersionToken is missing in the ABNF. Proposal: Add VersionToken = ("Version" / "V") Nancy & Abdallah -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com ------_=_NextPart_001_01BF92DE.2168BB10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable V16 review - Editorial comments

Brian, John,
I believe each of the following is an = editorial change to V16. You have both seen most of these already, and = commented on them - I am posting them to the megaco list this time, = with the proposed resolutions. Please comment!

1- Section 7.1.1 Specifying = Parameters
Issue: para. starting with = "Unspecified mandatory parameters
(i.e. mandatory parameters not = specified in a descriptor) result
in the command responder retaining = the previous value for that
parameter."

Comment: It seems that this section = applies only to mandatory fields in
Local and Remote descriptors (see = section 7.1.8). For example, when
a mandatory parameter is unspecified = in the Local descriptor,
then it retains the value it already = has. But, a mandatory parameter
in a ServiceChange HAS to be there I = would think. For example, the
ServiceChangeMethod descriptor is = mandatory, and must
always be present.

Proposal: Preface the quoted sentence = in 7.1.1 with "For Local and
Remote Descriptors, unspecified = mandatory parameters (i.e. mandatory
parameters not specified in a = descriptor) result in the ...."


2- Section 7.1.6 Stream = Descriptor
Issue: last sentence of first para, = "A stream is deleted by
setting empty Local and Remote = descriptors for the stream with
ReserveGroup and ReserveValue in = LocalControl set to "false" on
all terminations in the context that = previously supported that stream."

Comment: We don't have false or true = in the ABNF, only "ON/OFF". The
text uses both true/false, and = on/off.

Proposal: Make no changes to the text. = Just add this comment:
"ON =3D true, and OFF =3D = false" to the ABNF.


3- Section 7.1.7 LocalControl = Descriptor - ReserveGroup/ReserveValue
Issue: There is no explanation as to = what ReserveValue and
ReserveGroup mean.

Proposal: Add text something like the = following:
"In order to state that one = session description is to be selected
out of a list, ReserveGroup is set to = "false". If resources for all
session descriptions are to be = reserved, ReserveGroup is set
to "true". In order to = state that a parameter with a list of values,
e.g. multiple rtp payload types, = requires one value is to be
selected from the list, ReserveValue = is set to "false". If resources
for all values are to be reserved, = ReserveValue is set to "true". 
In other words, overspecifying by = giving a list of values can happen
independently at the session = description level and at the parameter
level. "

4- Section 7.1.9 Events Descriptor - = eventDM
Issue: eventDM is not mentioned in = this section while it is part of the
eventsDescriptor syntax.

Proposal: Add this sentence:
"If a digit map is required in = the EventsDescriptor, EventDM is used
to carry either the name or the value = of the digit map. See
section 7.1.14."


5- Section 7.1.11 Signals = Descriptor
Issue: setting of the signal list = type

Proposal: Add the following to section = 7.1.11:
* on/off in signal list
    -> it must be = the last element, and signal list type must be on/off
* timeout in signal list (and NO = on/off signals in the list)
     -> signal = list type must be timeout
* only brief signals in signal list =
    -> signal list = type defaults to brief.


6- Section 7.1.12 Audit Descriptor, = and also auditItem in the ABNF
Issue: the last entry in the table is = "EventBuffer". auditItem in the ABNF
does not qualify it either which is = incorrect.

Proposal: Change = "EventBuffer" to "EventBuffer Descriptor" in both = section 7.1.12
and in the ABNF.


7- Section 7.1.13 = ServiceChangeDescriptor
Issue: Extension is not part of the = enumeration

Comment: Is ServiceChangeDescriptor = supposed to be extendable or not?
The ABNF still has an extension = parameter in it.


8- Section 7.1.18 Topology = Descriptor
Issue: para starting with = "(T1,T2, bothway) means that ....
loopbacks are created by setting the = TerminationMode."

Comment: We don't have TerminationMode = any more.

Proposal: change it to read:
"...loopbacks are created by = setting the StreamMode property to LoopBack
in the = LocalControlDescriptor."


9- 7.2.5 Audit Value
Issue "W-" and = "O-"
Comment: Text does not describe that = wildcarded response
is qualified by "W-". Also, = no  text explaining that
optional commands are qualified by = "O-".

Proposal: in section  7.2.5, add = the following:
"The wildcard response option = (see section 6.2.2) is particularly useful
to limit the size of a n audit value = command which uses a wildcard
terminationId. In ASN.1 encoding = (Annex A), the flag "wildcardReturn"
is set on a command, and in ABNF = (Annex B), the command is qualified
by the "W-" = option."

Also, in section 8, add the = following:
"In ASN.1 encoding, the flag = "optional" is set on a command, and in the
ABNF, the command is qualified with = the "O-" option."


10- Section 7.2.6 = AuditCapabilities
Issue: AuditCapability API

Comment: same as in 9-Section = 7.2.5

Proposal: Add same sentences as above, = to this section.


11- Section 7.2.6 AuditCapabilities - = DigitMap and Packages
Issue: DigitMap and Packages in the = ABNF

Comment: The ABNF allows DigitMap and = Packages
in the return of AuditCapability. The = text says no. Need to
add a comment in the ABNF that = explains this.

Proposal: Add the following comment to = the ABNF:
"DigitMap and Packages are not = permitted to be part of
AuditCapabilities"


12- ANNEX B: signalListParm
Issue: signalListParm =3D = signalRequest

Comment: This is redundant.

Proposal: in the ABNF, signalRequest = should replace
signalListParm in signalList.


13- ANNEX B:digitMapValue
Issue: digitMapDescriptor =3D = DigitMapToken EQUAL digitMapName
( LBRKT digitMapValue RBRKT )

Comment: error with the round = brackets

Proposal: it should be
digitMapDescriptor =3D DigitMapToken = EQUAL digitMapName
[ LBRKT digitMapValue RBRKT ]


14- ANNEX B: version token
Issue: VersionToken is missing in the = ABNF.

Proposal: Add VersionToken =3D = ("Version" / "V")

Nancy & Abdallah

-----------------------------------------------------------------= ---------
Nancy M. Greene
Internet & Service = Provider Networks, Nortel Networks
T:514-271-7221 = (internal:ESN853-1077) E:ngreene@nortelnetworks.com

------_=_NextPart_001_01BF92DE.2168BB10-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 21 08:37:23 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11504 for ; Tue, 21 Mar 2000 08:37:23 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F2FD6AF0@standards.nortelnetworks.com>; Tue, 21 Mar 2000 8:32:10 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 96929 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Mar 2000 08:30:20 -0500 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B1503740@standards.nortelnetworks.com>; Tue, 21 Mar 2000 8:30:19 -0500 Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id PAA17099; Tue, 21 Mar 2000 15:34:41 +0200 (EET) Received: from loki.research.nokia.com (loki.research.nokia.com [172.21.33.76]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id PAA11600; Tue, 21 Mar 2000 15:34:36 +0200 (EET) Received: from rama.research.nokia.com (IDENT:root@rama.research.nokia.com [172.21.40.44]) by loki.research.nokia.com (8.9.3/8.9.3) with ESMTP id PAA25153; Tue, 21 Mar 2000 15:34:36 +0200 (EET) Received: (from ppessi@localhost) by rama.research.nokia.com (8.9.3/8.9.1) id PAA10563; Tue, 21 Mar 2000 15:34:35 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i References: <14551.23105.586855.679738@rama.research.nokia.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Message-ID: <14551.31339.481446.248782@rama.research.nokia.com> Date: Tue, 21 Mar 2000 15:34:35 +0200 Reply-To: Pekka.Pessi@nokia.com Sender: "Media Gateway Control (megaco)" From: Pekka Pessi Subject: Proposal: explain MEGACO protocol RFC status explicitly X-To: iesg@ietf.org To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <14551.23105.586855.679738@rama.research.nokia.com> Content-Transfer-Encoding: 7bit Hello all, The current MEGACO/H.248 draft, draft-ietf-megaco-protocol-07.txt, is still ongoing work. AFAIK the protocol is still incomplete and largely unimplementable. A reference implementation has just been started. The working group is planning to change the protocol semantics and transport syntax. There would be no point in publishing the document as an RFC, if this were an IETF-only project As I have understood, publishing incomplete recommendations is business as usual in ITU-T due to practical reasons. The ITU-T recommendations must be approved using time-consuming formal process, including a ballot. So, the finalized ITU-T specification actually consists of a recommendation document together with an Implementor's Guide correcting the errors and omissions in the recommendation document. IG may contain major changes that are incompatible with the published recommendation document. Also, when referring to a ITU-T specification, like H.323v2, people are actually referring to the recommendation together with the respective implementor's guide. The ITU-T process is (or at least should be) familiar to the developers using ITU-T recommendations. However, in Internet community people are expecting that the RFC is not just a snapshot of an on-going work. They don't anticipate that there is a companion document possibly changing the base protocol in every turn. Proposal I propose that the MEGACO RFC should contain a paragraph explaining the status of the text, ie. that the protocol will be changed by an Implementors' Guide published soon. The MEGACO RFC should also recommend that any reference to it must also be accompanied with a note explaining the status of the RFC, and a reference to the Implementors' Guide. Best regards, Pekka Pesi From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 21 09:03:17 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19835 for ; Tue, 21 Mar 2000 09:03:16 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.96120BD0@standards.nortelnetworks.com>; Tue, 21 Mar 2000 8:58:12 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 96953 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Mar 2000 08:56:27 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F1CAF380@standards.nortelnetworks.com>; Tue, 21 Mar 2000 8:46:27 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id IAA29011; Tue, 21 Mar 2000 08:50:55 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id IAA03756; Tue, 21 Mar 2000 08:50:51 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Mar 2000 08:46:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF208B36@whq-msgusr-02.fore.com> Date: Tue, 21 Mar 2000 08:50:12 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Proposal: explain MEGACO protocol RFC status explicitly X-To: "Pekka.Pessi@nokia.com" To: MEGACO@STANDARDS.NORTELNETWORKS.COM I disagree with your assessment of the state of the protocol. While there have been a series of text change proposals made in the last few weeks, all of them have either been requests to clear up language, or proposals to fix some minor errors for unusual circumstances. In no case, AFAIK, would any of the changes invalidate any existing implementation by more than a very minor addition. There are no plans for any major changes to syntax, and no changes at all to semantics, unless you consider clarification of intent to be a semantic change. I don't understand the "transport syntax" part at all, unless you are thinking about the ITU work on ATM transport and SCTP annexes, which will not carry through to the IETF version on present plans. There will be an erratum published with the RFC. Together, they should provide a stable basis for the protocol. The document is large. In any such document, there are things that could use more explanation. While an implementor's guide has been discussed, it has not yet been decided if we will need one. I suspect we will. The guide will not, if I have anything to do with it, change the protocol at all. If it needs to be changed, we will have to have a new RFC. Brian > -----Original Message----- > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > Sent: Tuesday, March 21, 2000 8:35 AM > To: MEGACO@standards.nortelnetworks.com > Subject: Proposal: explain MEGACO protocol RFC status explicitly > > > Hello all, > > The current MEGACO/H.248 draft, > draft-ietf-megaco-protocol-07.txt, > is still ongoing work. AFAIK the protocol is still > incomplete and > largely unimplementable. A reference implementation > has just been > started. The working group is planning to change the protocol > semantics and transport syntax. There would be no point in > publishing the document as an RFC, if this were an > IETF-only project > > As I have understood, publishing incomplete recommendations is > business as usual in ITU-T due to practical reasons. The ITU-T > recommendations must be approved using time-consuming formal > process, including a ballot. So, the finalized ITU-T > specification > actually consists of a recommendation document > together with an > Implementor's Guide correcting the errors and omissions in the > recommendation document. IG may contain major changes that are > incompatible with the published recommendation > document. Also, when > referring to a ITU-T specification, like H.323v2, people are > actually referring to the recommendation together with the > respective implementor's guide. > > The ITU-T process is (or at least should be) familiar to the > developers using ITU-T recommendations. However, in Internet > community people are expecting that the RFC is not > just a snapshot > of an on-going work. They don't anticipate that there > is a companion > document possibly changing the base protocol in every turn. > > Proposal > > I propose that the MEGACO RFC should contain a > paragraph explaining > the status of the text, ie. that the protocol will be > changed by an > Implementors' Guide published soon. The MEGACO RFC should also > recommend that any reference to it must also be > accompanied with a > note explaining the status of the RFC, and a reference to the > Implementors' Guide. > > Best regards, > Pekka Pesi > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 21 10:36:30 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26394 for ; Tue, 21 Mar 2000 10:36:29 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9B00F130@standards.nortelnetworks.com>; Tue, 21 Mar 2000 10:31:23 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 97029 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Mar 2000 10:29:35 -0500 Received: from internal.mediatrix.com (205.237.248.36) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5A08DCB0@standards.nortelnetworks.com>; Tue, 21 Mar 2000 10:29:34 -0500 Received: by INTERNAL with Internet Mail Service (5.5.2448.0) id ; Tue, 21 Mar 2000 10:35:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <80E2FF0AC64DD311AC3700E02910AE0A02FE98@INTERNAL> Date: Tue, 21 Mar 2000 10:35:12 -0500 Reply-To: Gordon Cutts Sender: "Media Gateway Control (megaco)" From: Gordon Cutts Subject: KeepAlive and DigitMaps X-cc: ML_APA-III-4-NT To: MEGACO@STANDARDS.NORTELNETWORKS.COM To whom it may concern, Once again I have a question regarding MGCP, but unfortunately the thread traffic is all but dead at mgcp@pulver.com so I am forced to use this list .. I hope nobody is bothered too much by this :) Brief history of the problem: > Will they support our shortcut for digits of keeping the digit request > 'alive' until overwritten by another request? If not, DigitMap will cover > the initial dialing of digits, but not the feature interface. 'KeepAlive' > may be the option we use to tell them this request must remain alive until > canceled. > > [Gordon] I don't see how the requested action (K) can be used on a requested > event such as "R: D/[0-9#*T](N)" My understanding of "K" is that it is for > "Keep Signal(s) Active", and not for keeping events active. If you give us > the following requested event "R: D/[0-9#*T](N)" the behaviour is for the > gateway to report the DTMF when it occurs and continue doing so until it > receives a response. Basically the Call Agent wants to have a digit map that will support DTMFs during the call for the purpose of calling cards etc. This would require a digit map that could cover every possible number combination and would therefore be much too large. The alternative [X.T] is not acceptable due to the timeout factor being too slow. The solution, notify the CA as DTMFs are received, with the following request: "R: D/[0-9#*T](N)". Unfortunately this requires a new digit map after every NTFY for a DTMF is sent to the CA. The action in question now is "K", the KeepAlive action. So as to not be repetitive my opinion can be seen above. I was hoping to get some feedback on the true behavior of the action "K" before I change anything and risk becoming too proprietary. Thanks to all in advance. Regards, Gordon Cutts From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 21 11:36:42 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18451 for ; Tue, 21 Mar 2000 11:36:40 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FF5C30B0@standards.nortelnetworks.com>; Tue, 21 Mar 2000 11:31:28 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 97068 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Mar 2000 11:30:18 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6FD2B230@standards.nortelnetworks.com>; Tue, 21 Mar 2000 11:20:17 -0500 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id IAA27602; Tue, 21 Mar 2000 08:24:44 -0800 (PST) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <80E2FF0AC64DD311AC3700E02910AE0A02FE98@INTERNAL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38D7CD11.9F253A61@cisco.com> Date: Tue, 21 Mar 2000 11:27:13 -0800 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Organization: Cisco Systems Subject: Re: KeepAlive and DigitMaps X-To: Gordon Cutts X-cc: mgcp@pulver.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi Gordon Gordon Cutts wrote: > To whom it may concern, > > Once again I have a question regarding MGCP, but unfortunately the thread > traffic is all but dead at mgcp@pulver.com so I am forced to use this list > .. I hope nobody is bothered too much by this :) > > Brief history of the problem: > > > Will they support our shortcut for digits of keeping the digit request > > 'alive' until overwritten by another request? If not, DigitMap will cover > > the initial dialing of digits, but not the feature interface. 'KeepAlive' > > may be the option we use to tell them this request must remain alive until > > canceled. I'm not sure I follow this, as my comments below may reflect. Please let me know if I misunderstood. > > > > > [Gordon] I don't see how the requested action (K) can be used on a > requested > > event such as "R: D/[0-9#*T](N)" My understanding of "K" is that it is > for > > "Keep Signal(s) Active", and not for keeping events active. Correct. > If you give > us > > the following requested event "R: D/[0-9#*T](N)" the behaviour is for the > > gateway to report the DTMF when it occurs Yes. > and continue doing so until it > > receives a response. I assume you refer to retransmission here, otherwise I'm not sure I follow. You probably only wanted to do this using "loop" mode, in which case you would continue doing so until you get a new RQNT (encapsulated or not). > > > Basically the Call Agent wants to have a digit map that will support DTMFs > during the call for the purpose of calling cards etc. This would require a > digit map that could cover every possible number combination and would > therefore be much too large. The alternative [X.T] is not acceptable due to > the timeout factor being too slow. The solution, notify the CA as DTMFs are > received, with the following request: "R: D/[0-9#*T](N)". Unfortunately > this requires a new digit map after every NTFY for a DTMF is sent to the CA. The way the request is shown, there is no digit map in the MG - DTMF events are simply reported as they are detected. Also, if you use "loop" mode, you can send more than one NTFY per RQNT. > > The action in question now is "K", the KeepAlive action. So as to not be > repetitive my opinion can be seen above. > > I was hoping to get some feedback on the true behavior of the action "K" > before I change anything and risk becoming too proprietary. The only thing the "K" action would give you, is to keep signals active on DTMF input. For example, if you had some tone playing, and you didn't want it to be interrupted by DMTF input, you could use this. In this particular case, I suspect that's not quite what you are looking for though. > > > Thanks to all in advance. > > Regards, > > Gordon Cutts Regards Flemming -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 21 11:36:43 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18466 for ; Tue, 21 Mar 2000 11:36:42 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.FFEB5150@standards.nortelnetworks.com>; Tue, 21 Mar 2000 11:31:29 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 97090 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Mar 2000 11:31:08 -0500 Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F35D5BE0@standards.nortelnetworks.com>; Tue, 21 Mar 2000 11:31:08 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id RAA00211; Tue, 21 Mar 2000 17:35:37 +0100 (MET) 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 RAA05945; Tue, 21 Mar 2000 17:35:36 +0100 (MET) Received: from ericsson.com (kipe126.eraj.ericsson.se [147.214.68.126]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id RAA27398; Tue, 21 Mar 2000 17:35:36 +0100 (MET) X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <14551.23105.586855.679738@rama.research.nokia.com> <14551.31339.481446.248782@rama.research.nokia.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <38D7A4D3.9C45CB78@ericsson.com> Date: Tue, 21 Mar 2000 17:35:31 +0100 Reply-To: Stephen Terrill Sender: "Media Gateway Control (megaco)" From: Stephen Terrill Organization: L.M. Ericsson Subject: Re: Proposal: explain MEGACO protocol RFC status explicitly X-To: Pekka.Pessi@nokia.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hi, Like Brian, I don´t agree with your summary of the status of the protocol. Sometimes after stablisation there is considerations for ongoing development of a protocol (ie the next version in ITU-T terms, or a new RFC in IETF terms), or errata which is to be corrected. So far I understood the agreed changes to be minor &/or clarification in nature. My understanding of the implementors guide, if there is to be one, is that the information contained in that is to be lifted to version 2 of the protocol, if there is one. I am not sure what is meant by the change in transport syntax. Regards, ..//Steve Pekka Pessi wrote: > Hello all, > > The current MEGACO/H.248 draft, draft-ietf-megaco-protocol-07.txt, > is still ongoing work. AFAIK the protocol is still incomplete and > largely unimplementable. A reference implementation has just been > started. The working group is planning to change the protocol > semantics and transport syntax. There would be no point in > publishing the document as an RFC, if this were an IETF-only project > > As I have understood, publishing incomplete recommendations is > business as usual in ITU-T due to practical reasons. The ITU-T > recommendations must be approved using time-consuming formal > process, including a ballot. So, the finalized ITU-T specification > actually consists of a recommendation document together with an > Implementor's Guide correcting the errors and omissions in the > recommendation document. IG may contain major changes that are > incompatible with the published recommendation document. Also, when > referring to a ITU-T specification, like H.323v2, people are > actually referring to the recommendation together with the > respective implementor's guide. > > The ITU-T process is (or at least should be) familiar to the > developers using ITU-T recommendations. However, in Internet > community people are expecting that the RFC is not just a snapshot > of an on-going work. They don't anticipate that there is a companion > document possibly changing the base protocol in every turn. > > Proposal > > I propose that the MEGACO RFC should contain a paragraph explaining > the status of the text, ie. that the protocol will be changed by an > Implementors' Guide published soon. The MEGACO RFC should also > recommend that any reference to it must also be accompanied with a > note explaining the status of the RFC, and a reference to the > Implementors' Guide. > > Best regards, > Pekka Pesi From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 21 12:18:53 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03544 for ; Tue, 21 Mar 2000 12:18:52 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E53D1EF0@standards.nortelnetworks.com>; Tue, 21 Mar 2000 12:13:41 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 97229 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Mar 2000 12:12:03 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AA8736B0@standards.nortelnetworks.com>; Tue, 21 Mar 2000 12:12:02 -0500 Received: from chsharp-tecra.cisco.com (chsharp-isdn.cisco.com [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id JAA21139; Tue, 21 Mar 2000 09:16:26 -0800 (PST) X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.1.2.20000321101230.00b5b410@dogwood.cisco.com> Date: Tue, 21 Mar 2000 12:02:51 -0800 Reply-To: Chip Sharp Sender: "Media Gateway Control (megaco)" From: Chip Sharp Subject: Re: Proposal: explain MEGACO protocol RFC status explicitly X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4FBEA8857476D311A03300204840E1CF208B36@whq-msgusr-02.fore. com> As a further clarification, independent of any judgement on megaco/H.248 in particular, publication of any RFC as Proposed Standard is really a snapshot of the development of the protocol. At the point of publication of the RFC as Proposed Standard, the protocol is considered stable enough to begin implementation, perform interoperability tests and perhaps get some deployment experience (not necessarily in production networks). If during this process, problems are found in the protocol and corrections are needed, a new RFC can be published with the corrections while still remaining in Proposed Standard state. There is no requirement to implement an I-D before it moves to Proposed Standard. Sometimes this is done and it definitely helps to get this experience to learn the ins and outs as the protocol is developed, but it is not required. As far as megaco/H.248 is concerned, I do believe something like implementer's agreements (or profiles) will have to be worked out for interoperability reasons for specific applications since there are so many options and different ways of doing the same thing. Although there are details we all don't agree on, the IP Phone profile is one attempt at doing this for an IP Phone application. One thing to keep in mind is that before megaco can move to Draft Standard in IETF, all options that don't have multiple interoperable implementations have to be removed. Chip At 08:50 AM 3/21/00 -0500, Rosen, Brian wrote: >I disagree with your assessment of the state of the protocol. > >While there have been a series of text change proposals made >in the last few weeks, all of them have either been requests >to clear up language, or proposals to fix some minor errors for >unusual circumstances. In no case, AFAIK, would any of the changes >invalidate any existing implementation by more than a very minor >addition. There are no plans for any major changes to syntax, >and no changes at all to semantics, unless you consider clarification >of intent to be a semantic change. I don't understand the "transport >syntax" part at all, unless you are thinking about the ITU work >on ATM transport and SCTP annexes, which will not carry through to the >IETF version on present plans. > >There will be an erratum published with the RFC. Together, they >should provide a stable basis for the protocol. The document is large. >In any such document, there are things that could use more explanation. >While an implementor's guide has been discussed, it has not yet >been decided if we will need one. I suspect we will. The guide will >not, if I have anything to do with it, change the protocol at all. >If it needs to be changed, we will have to have a new RFC. > >Brian > > > -----Original Message----- > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > Sent: Tuesday, March 21, 2000 8:35 AM > > To: MEGACO@standards.nortelnetworks.com > > Subject: Proposal: explain MEGACO protocol RFC status explicitly > > > > > > Hello all, > > > > The current MEGACO/H.248 draft, > > draft-ietf-megaco-protocol-07.txt, > > is still ongoing work. AFAIK the protocol is still > > incomplete and > > largely unimplementable. A reference implementation > > has just been > > started. The working group is planning to change the protocol > > semantics and transport syntax. There would be no point in > > publishing the document as an RFC, if this were an > > IETF-only project > > > > As I have understood, publishing incomplete recommendations is > > business as usual in ITU-T due to practical reasons. The ITU-T > > recommendations must be approved using time-consuming formal > > process, including a ballot. So, the finalized ITU-T > > specification > > actually consists of a recommendation document > > together with an > > Implementor's Guide correcting the errors and omissions in the > > recommendation document. IG may contain major changes that are > > incompatible with the published recommendation > > document. Also, when > > referring to a ITU-T specification, like H.323v2, people are > > actually referring to the recommendation together with the > > respective implementor's guide. > > > > The ITU-T process is (or at least should be) familiar to the > > developers using ITU-T recommendations. However, in Internet > > community people are expecting that the RFC is not > > just a snapshot > > of an on-going work. They don't anticipate that there > > is a companion > > document possibly changing the base protocol in every turn. > > > > Proposal > > > > I propose that the MEGACO RFC should contain a > > paragraph explaining > > the status of the text, ie. that the protocol will be > > changed by an > > Implementors' Guide published soon. The MEGACO RFC should also > > recommend that any reference to it must also be > > accompanied with a > > note explaining the status of the RFC, and a reference to the > > Implementors' Guide. > > > > Best regards, > > Pekka Pesi > > Support NetAid! http://www.netaid.org -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. -------------------------------------------------- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 21 12:40:03 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11343 for ; Tue, 21 Mar 2000 12:40:02 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DC018170@standards.nortelnetworks.com>; Tue, 21 Mar 2000 12:34:54 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 97307 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Mar 2000 12:33:33 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.45C0F4D0@standards.nortelnetworks.com>; Tue, 21 Mar 2000 12:23:32 -0500 Received: from zcard015.ca.nortel.com (actually zcard015) by smtprch1.nortel.com; Tue, 21 Mar 2000 10:08:01 -0600 Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HAZ4PAHG; Tue, 21 Mar 2000 11:07:16 -0500 Received: from nortelnetworks.com (pnc1m006.us.nortel.com [47.142.208.218]) by zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id FL1S8XDC; Tue, 21 Mar 2000 11:07:15 -0500 X-Sybari-Space: 00000000 00000000 00000000 X-Sender: "Michael Brown" X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF208B36@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38D79EF6.99C2B100@nortelnetworks.com> Date: Tue, 21 Mar 2000 11:10:30 -0500 Reply-To: Michael Brown Sender: "Media Gateway Control (megaco)" From: Michael Brown Organization: Nortel Networks Subject: Re: Proposal: explain MEGACO protocol RFC status explicitly To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I also disagree with the initially posted assessment that the protocol is incomplete and unimplementable. I can confirm that the recent changes have indeed resulted in only very minor changes to implementation. I don't think there is anything else to add to Brian's description of the way forward and completely agree with his assertion that the RFC and the erratum will indeed provide a clear and stable basis for the protocol. Michael Brown "Rosen, Brian" wrote: > I disagree with your assessment of the state of the protocol. > > While there have been a series of text change proposals made > in the last few weeks, all of them have either been requests > to clear up language, or proposals to fix some minor errors for > unusual circumstances. In no case, AFAIK, would any of the changes > invalidate any existing implementation by more than a very minor > addition. There are no plans for any major changes to syntax, > and no changes at all to semantics, unless you consider clarification > of intent to be a semantic change. I don't understand the "transport > syntax" part at all, unless you are thinking about the ITU work > on ATM transport and SCTP annexes, which will not carry through to the > IETF version on present plans. > > There will be an erratum published with the RFC. Together, they > should provide a stable basis for the protocol. The document is large. > In any such document, there are things that could use more explanation. > While an implementor's guide has been discussed, it has not yet > been decided if we will need one. I suspect we will. The guide will > not, if I have anything to do with it, change the protocol at all. > If it needs to be changed, we will have to have a new RFC. > > Brian > > > -----Original Message----- > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > Sent: Tuesday, March 21, 2000 8:35 AM > > To: MEGACO@standards.nortelnetworks.com > > Subject: Proposal: explain MEGACO protocol RFC status explicitly > > > > > > Hello all, > > > > The current MEGACO/H.248 draft, > > draft-ietf-megaco-protocol-07.txt, > > is still ongoing work. AFAIK the protocol is still > > incomplete and > > largely unimplementable. A reference implementation > > has just been > > started. The working group is planning to change the protocol > > semantics and transport syntax. There would be no point in > > publishing the document as an RFC, if this were an > > IETF-only project > > > > As I have understood, publishing incomplete recommendations is > > business as usual in ITU-T due to practical reasons. The ITU-T > > recommendations must be approved using time-consuming formal > > process, including a ballot. So, the finalized ITU-T > > specification > > actually consists of a recommendation document > > together with an > > Implementor's Guide correcting the errors and omissions in the > > recommendation document. IG may contain major changes that are > > incompatible with the published recommendation > > document. Also, when > > referring to a ITU-T specification, like H.323v2, people are > > actually referring to the recommendation together with the > > respective implementor's guide. > > > > The ITU-T process is (or at least should be) familiar to the > > developers using ITU-T recommendations. However, in Internet > > community people are expecting that the RFC is not > > just a snapshot > > of an on-going work. They don't anticipate that there > > is a companion > > document possibly changing the base protocol in every turn. > > > > Proposal > > > > I propose that the MEGACO RFC should contain a > > paragraph explaining > > the status of the text, ie. that the protocol will be > > changed by an > > Implementors' Guide published soon. The MEGACO RFC should also > > recommend that any reference to it must also be > > accompanied with a > > note explaining the status of the RFC, and a reference to the > > Implementors' Guide. > > > > Best regards, > > Pekka Pesi > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 21 14:21:17 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21555 for ; Tue, 21 Mar 2000 14:21:17 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0072B250@standards.nortelnetworks.com>; Tue, 21 Mar 2000 14:16:08 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 97478 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Mar 2000 14:14:10 -0500 Received: from noc.techcontrol.com (207.94.33.111) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.54350700@standards.nortelnetworks.com>; Tue, 21 Mar 2000 14:04:09 -0500 Received: from dbutlerlp ([10.2.3.98]) by noc.techcontrol.com (8.9.3/8.9.0.Beta5) with SMTP id OAA13656; Tue, 21 Mar 2000 14:16:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Message-ID: <001a01bf9369$1f5e8300$6203020a@techcontrol.com> Date: Tue, 21 Mar 2000 14:10:27 -0500 Reply-To: David Butler Sender: "Media Gateway Control (megaco)" From: David Butler Subject: Re: [MGCP]: Re: KeepAlive and DigitMaps X-To: Flemming Andreasen , Gordon Cutts X-cc: mgcp@Pulver.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <38D7CD11.9F253A61@cisco.com> Content-Transfer-Encoding: 7bit To whom it may concern, I have been tailing the MGCP group communications and wish to include other members of the team here at TCS. Can someone tell us how to subscribe. Thanks, David Butler/TCS -----Original Message----- From: owner-iptelephony-news@Pulver.COM [mailto:owner-iptelephony-news@Pulver.COM] On Behalf Of Flemming Andreasen Sent: Tuesday, March 21, 2000 2:27 PM To: Gordon Cutts Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM; mgcp@Pulver.COM Subject: [MGCP]: Re: KeepAlive and DigitMaps Hi Gordon Gordon Cutts wrote: > To whom it may concern, > > Once again I have a question regarding MGCP, but unfortunately the thread > traffic is all but dead at mgcp@pulver.com so I am forced to use this list > .. I hope nobody is bothered too much by this :) > > Brief history of the problem: > > > Will they support our shortcut for digits of keeping the digit request > > 'alive' until overwritten by another request? If not, DigitMap will cover > > the initial dialing of digits, but not the feature interface. 'KeepAlive' > > may be the option we use to tell them this request must remain alive until > > canceled. I'm not sure I follow this, as my comments below may reflect. Please let me know if I misunderstood. > > > > > [Gordon] I don't see how the requested action (K) can be used on a > requested > > event such as "R: D/[0-9#*T](N)" My understanding of "K" is that it is > for > > "Keep Signal(s) Active", and not for keeping events active. Correct. > If you give > us > > the following requested event "R: D/[0-9#*T](N)" the behaviour is for the > > gateway to report the DTMF when it occurs Yes. > and continue doing so until it > > receives a response. I assume you refer to retransmission here, otherwise I'm not sure I follow. You probably only wanted to do this using "loop" mode, in which case you would continue doing so until you get a new RQNT (encapsulated or not). > > > Basically the Call Agent wants to have a digit map that will support DTMFs > during the call for the purpose of calling cards etc. This would require a > digit map that could cover every possible number combination and would > therefore be much too large. The alternative [X.T] is not acceptable due to > the timeout factor being too slow. The solution, notify the CA as DTMFs are > received, with the following request: "R: D/[0-9#*T](N)". Unfortunately > this requires a new digit map after every NTFY for a DTMF is sent to the CA. The way the request is shown, there is no digit map in the MG - DTMF events are simply reported as they are detected. Also, if you use "loop" mode, you can send more than one NTFY per RQNT. > > The action in question now is "K", the KeepAlive action. So as to not be > repetitive my opinion can be seen above. > > I was hoping to get some feedback on the true behavior of the action "K" > before I change anything and risk becoming too proprietary. The only thing the "K" action would give you, is to keep signals active on DTMF input. For example, if you had some tone playing, and you didn't want it to be interrupted by DMTF input, you could use this. In this particular case, I suspect that's not quite what you are looking for though. > > > Thanks to all in advance. > > Regards, > > Gordon Cutts Regards Flemming -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 21 14:29:09 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24718 for ; Tue, 21 Mar 2000 14:29:09 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.20118680@standards.nortelnetworks.com>; Tue, 21 Mar 2000 14:24:11 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 97479 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Mar 2000 14:23:23 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9AB5ED60@standards.nortelnetworks.com>; Tue, 21 Mar 2000 14:13:17 -0500 Received: from cisco.com (ssh.cisco.com [171.69.10.34]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id LAA24914; Tue, 21 Mar 2000 11:16:59 -0800 (PST) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <001a01bf9369$1f5e8300$6203020a@techcontrol.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38D7F570.D4038740@cisco.com> Date: Tue, 21 Mar 2000 14:19:28 -0800 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Organization: Cisco Systems Subject: Re: [MGCP]: Re: KeepAlive and DigitMaps X-To: David Butler X-cc: Gordon Cutts , mgcp@Pulver.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Sure Just send a message to "majordomo@pulver.com" with "subscribe mgcp" in the message body. Regards Flemming David Butler wrote: > To whom it may concern, > > I have been tailing the MGCP group communications and wish to include other > members of the team here at TCS. Can someone tell us how to subscribe. > > Thanks, > > David Butler/TCS > > -----Original Message----- > From: owner-iptelephony-news@Pulver.COM > [mailto:owner-iptelephony-news@Pulver.COM] On Behalf Of Flemming Andreasen > Sent: Tuesday, March 21, 2000 2:27 PM > To: Gordon Cutts > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM; mgcp@Pulver.COM > Subject: [MGCP]: Re: KeepAlive and DigitMaps > > Hi Gordon > > Gordon Cutts wrote: > > > To whom it may concern, > > > > Once again I have a question regarding MGCP, but unfortunately the thread > > traffic is all but dead at mgcp@pulver.com so I am forced to use this list > > > .. I hope nobody is bothered too much by this :) > > > > Brief history of the problem: > > > > > Will they support our shortcut for digits of keeping the digit request > > > 'alive' until overwritten by another request? If not, DigitMap will > cover > > > the initial dialing of digits, but not the feature interface. > 'KeepAlive' > > > may be the option we use to tell them this request must remain alive > until > > > canceled. > > I'm not sure I follow this, as my comments below may reflect. Please let me > know > if I misunderstood. > > > > > > > > > [Gordon] I don't see how the requested action (K) can be used on a > > requested > > > event such as "R: D/[0-9#*T](N)" My understanding of "K" is that it is > > for > > > "Keep Signal(s) Active", and not for keeping events active. > > Correct. > > > If you give > > us > > > the following requested event "R: D/[0-9#*T](N)" the behaviour is for > the > > > gateway to report the DTMF when it occurs > > Yes. > > > and continue doing so until it > > > receives a response. > > I assume you refer to retransmission here, otherwise I'm not sure I follow. > You > probably only wanted to do this using "loop" mode, in which case you would > continue doing so until you get a new RQNT (encapsulated or not). > > > > > > > Basically the Call Agent wants to have a digit map that will support DTMFs > > during the call for the purpose of calling cards etc. This would require > a > > digit map that could cover every possible number combination and would > > therefore be much too large. The alternative [X.T] is not acceptable due > to > > the timeout factor being too slow. The solution, notify the CA as DTMFs > are > > received, with the following request: "R: D/[0-9#*T](N)". Unfortunately > > this requires a new digit map after every NTFY for a DTMF is sent to the > CA. > > The way the request is shown, there is no digit map in the MG - DTMF events > are > simply reported as they are detected. Also, if you use "loop" mode, you can > send > more than one NTFY per RQNT. > > > > > The action in question now is "K", the KeepAlive action. So as to not be > > repetitive my opinion can be seen above. > > > > I was hoping to get some feedback on the true behavior of the action "K" > > before I change anything and risk becoming too proprietary. > > The only thing the "K" action would give you, is to keep signals active on > DTMF > input. For example, if you had some tone playing, and you didn't want it to > be > interrupted by DMTF input, you could use this. In this particular case, I > suspect that's not quite what you are looking for though. > > > > > > > Thanks to all in advance. > > > > Regards, > > > > Gordon Cutts > > Regards > > Flemming > > -- > Flemming Andreasen > Cisco Systems -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 21 19:13:52 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09150 for ; Tue, 21 Mar 2000 19:13:52 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E61FF880@standards.nortelnetworks.com>; Tue, 21 Mar 2000 19:08:53 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 98023 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Mar 2000 19:07:19 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4353E770@standards.nortelnetworks.com>; Tue, 21 Mar 2000 18:57:11 -0500 Received: from zcard015.ca.nortel.com (actually zcard015) by smtprch1.nortel.com; Tue, 21 Mar 2000 17:59:18 -0600 Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HAZ4P1LJ; Tue, 21 Mar 2000 18:57:35 -0500 Received: from nortelnetworks.com (pnc1m006.us.nortel.com [47.142.208.218]) by zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id FL1S8ZL6; Tue, 21 Mar 2000 18:57:33 -0500 X-Sybari-Space: 00000000 00000000 00000000 X-Sender: "Michael Brown" X-Mailer: Mozilla 4.7 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------EA7B865A1C6B77B2F5857A08" Message-ID: <38D80D07.8E455FD5@nortelnetworks.com> Date: Tue, 21 Mar 2000 19:00:07 -0500 Reply-To: Michael Brown Sender: "Media Gateway Control (megaco)" From: Michael Brown Organization: Nortel Networks Subject: FW: I-D ACTION:draft-brown-supplpkgs-00.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM --------------EA7B865A1C6B77B2F5857A08 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello all, I was just forwarded the following with the explanation that by leaving megaco out of the title, this draft would not have been announced specifically to the WG. Sorry for the delay in announcing this draft and I hope that people will have time to take a look at it as I would like to present/discuss it in Adelaide. Cheers, Michael ---------- From: Internet-Drafts@ietf.org[SMTP:Internet-Drafts@ietf.org] Sent: Friday, March 17, 2000 8:22 AM To: IETF-Announce Subject: I-D ACTION:draft-brown-supplpkgs-00.txt <<...>> A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Supplemental Packages for Megaco/H.248 Author(s) : C. Brown, K. Chapman, K. Boyle Filename : draft-brown-supplpkgs-00.txt Pages : Date : 16-Mar-00 This document provides proposed definitions for several supplemental packages for Megaco/H.248. These packages address support of functionality for basic and enhanced telephony services, and PSTN Per Trunk Signaling (PTS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brown-supplpkgs-00.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-brown-supplpkgs-00.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-brown-supplpkgs-00.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. --------------EA7B865A1C6B77B2F5857A08 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello all,

  I was just forwarded the following with the explanation that by leaving megaco out of the title, this draft would not have been announced specifically to the WG. Sorry for the delay in announcing this draft and I hope that people will have time to take a look at it as I would like to present/discuss it in Adelaide.

Cheers,

Michael

       
    ----------
    From:   Internet-Drafts@ietf.org[SMTP:Internet-Drafts@ietf.org]
    Sent:   Friday, March 17, 2000 8:22 AM
    To:     IETF-Announce
    Subject:        I-D ACTION:draft-brown-supplpkgs-00.txt

    <<...>>
    A New Internet-Draft is available from the on-line Internet-Drafts directories.

            Title           : Supplemental Packages for Megaco/H.248
            Author(s)       : C. Brown, K. Chapman,  K. Boyle
            Filename        : draft-brown-supplpkgs-00.txt
            Pages           :
            Date            : 16-Mar-00

    This document provides proposed definitions for several supplemental
    packages for Megaco/H.248. These packages address support of
    functionality for basic and enhanced telephony services, and PSTN
    Per Trunk Signaling (PTS).

    A URL for this Internet-Draft is:
    http://www.ietf.org/internet-drafts/draft-brown-supplpkgs-00.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-brown-supplpkgs-00.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-brown-supplpkgs-00.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.
     

--------------EA7B865A1C6B77B2F5857A08-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 21 22:23:10 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19497 for ; Tue, 21 Mar 2000 22:23:09 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.573122A0@standards.nortelnetworks.com>; Tue, 21 Mar 2000 22:18:10 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 98223 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Mar 2000 22:16:19 -0500 Received: from ish7.ericsson.com.au (203.61.155.111) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.AF51A150@standards.nortelnetworks.com>; Tue, 21 Mar 2000 22:06:19 -0500 Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.1) with ESMTP id OAA05877 for ; Wed, 22 Mar 2000 14:10:05 +1100 (EST) Received: from mcsi00.epa.ericsson.se (mcsi00 [146.11.8.201]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id OAA08811 for ; Wed, 22 Mar 2000 14:10:45 +1100 (EST) Received: from ericsson.com (mc2dh6.epa.ericsson.se [146.11.87.6]) by mcsi00.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA15751 for ; Wed, 22 Mar 2000 14:10:00 +1100 (EST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF208B36@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38D83991.9BD45A7A@ericsson.com> Date: Wed, 22 Mar 2000 14:10:09 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Proposal: explain MEGACO protocol RFC status explicitly To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day all, I agree with Brian on this. The protocol is stable. The things that concern us currently are minor errors. If identified these should be fixed. Other clarifications can be in an implementor's guide or clarified in version 2 of the protocol. What is currently in H248 is more than sufficient to implement against. Regards, Christian "Rosen, Brian" wrote: > > I disagree with your assessment of the state of the protocol. > > While there have been a series of text change proposals made > in the last few weeks, all of them have either been requests > to clear up language, or proposals to fix some minor errors for > unusual circumstances. In no case, AFAIK, would any of the changes > invalidate any existing implementation by more than a very minor > addition. There are no plans for any major changes to syntax, > and no changes at all to semantics, unless you consider clarification > of intent to be a semantic change. I don't understand the "transport > syntax" part at all, unless you are thinking about the ITU work > on ATM transport and SCTP annexes, which will not carry through to the > IETF version on present plans. > > There will be an erratum published with the RFC. Together, they > should provide a stable basis for the protocol. The document is large. > In any such document, there are things that could use more explanation. > While an implementor's guide has been discussed, it has not yet > been decided if we will need one. I suspect we will. The guide will > not, if I have anything to do with it, change the protocol at all. > If it needs to be changed, we will have to have a new RFC. > > Brian > > > -----Original Message----- > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > Sent: Tuesday, March 21, 2000 8:35 AM > > To: MEGACO@standards.nortelnetworks.com > > Subject: Proposal: explain MEGACO protocol RFC status explicitly > > > > > > Hello all, > > > > The current MEGACO/H.248 draft, > > draft-ietf-megaco-protocol-07.txt, > > is still ongoing work. AFAIK the protocol is still > > incomplete and > > largely unimplementable. A reference implementation > > has just been > > started. The working group is planning to change the protocol > > semantics and transport syntax. There would be no point in > > publishing the document as an RFC, if this were an > > IETF-only project > > > > As I have understood, publishing incomplete recommendations is > > business as usual in ITU-T due to practical reasons. The ITU-T > > recommendations must be approved using time-consuming formal > > process, including a ballot. So, the finalized ITU-T > > specification > > actually consists of a recommendation document > > together with an > > Implementor's Guide correcting the errors and omissions in the > > recommendation document. IG may contain major changes that are > > incompatible with the published recommendation > > document. Also, when > > referring to a ITU-T specification, like H.323v2, people are > > actually referring to the recommendation together with the > > respective implementor's guide. > > > > The ITU-T process is (or at least should be) familiar to the > > developers using ITU-T recommendations. However, in Internet > > community people are expecting that the RFC is not > > just a snapshot > > of an on-going work. They don't anticipate that there > > is a companion > > document possibly changing the base protocol in every turn. > > > > Proposal > > > > I propose that the MEGACO RFC should contain a > > paragraph explaining > > the status of the text, ie. that the protocol will be > > changed by an > > Implementors' Guide published soon. The MEGACO RFC should also > > recommend that any reference to it must also be > > accompanied with a > > note explaining the status of the RFC, and a reference to the > > Implementors' Guide. > > > > Best regards, > > Pekka Pesi > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 21 22:39:19 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26421 for ; Tue, 21 Mar 2000 22:39:18 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.94F60DB0@standards.nortelnetworks.com>; Tue, 21 Mar 2000 22:34:12 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 98251 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 21 Mar 2000 22:33:01 -0500 Received: from ish7.ericsson.com.au (203.61.155.111) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.045CA5D0@standards.nortelnetworks.com>; Tue, 21 Mar 2000 22:23:00 -0500 Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.1) with ESMTP id OAA07305; Wed, 22 Mar 2000 14:26:53 +1100 (EST) Received: from mcsi00.epa.ericsson.se (mcsi00 [146.11.8.201]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id OAA11324; Wed, 22 Mar 2000 14:27:33 +1100 (EST) Received: from ericsson.com (mc2dh6.epa.ericsson.se [146.11.87.6]) by mcsi00.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA16279; Wed, 22 Mar 2000 14:26:48 +1100 (EST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4.3.1.2.20000321101230.00b5b410@dogwood.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38D83D80.924F5993@ericsson.com> Date: Wed, 22 Mar 2000 14:26:56 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Interop > Re: Proposal: explain MEGACO protocol RFC status explicitly X-cc: Chip Sharp To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day all, Chip raises an interesting issue of interoperability tests. The current plans for such testing seems to me to be ambiguous at best. Due to the generic nature of Megaco it seems to me to be quite difficult to test. From what I have seen (please correct me if this isn't the case) is that Megaco/H248 is planned to be tested as part of a larger application test. ie. trunking gateway, IP phone etc. This to me seems a lot of overhead just to test the megaco protocol. It also seems to put certain players of the interop test. ie. if I make SIP GW which have h248 but the interop test covers IP phones how do I get my Megaco stack tested??? Are there any initiatives where something similar to the following approach is taken? Do people see merit in this? o The test is a test of the protocol mechanisms. o Test between 2 boxes (PCs, workstations etc) that implement H248 with the necessary SW to drive the test. These boxes would be application agnostic. o A test package could be developed with "dummy" properties, events, signals etc. o A test case document which lists test cases for a good coverage test of Megaco. These test cases could describe what should occur at dummy event detection. The aim of the approach is an interop where people who intend to implement Megaco but not in one of the proposed applications can test there stacks without having to implement an entire application. If anyone has any information of the current status of Megaco interops can they please share it on the list. Cheers, Christian Chip Sharp wrote: > > As a further clarification, independent of any judgement on megaco/H.248 in > particular, publication of any RFC as Proposed Standard is really a > snapshot of the development of the protocol. At the point of publication > of the RFC as Proposed Standard, the protocol is considered stable enough > to begin implementation, perform interoperability tests and perhaps get > some deployment experience (not necessarily in production networks). > > If during this process, problems are found in the protocol and corrections > are needed, a new RFC can be published with the corrections while still > remaining in Proposed Standard state. > > There is no requirement to implement an I-D before it moves to Proposed > Standard. Sometimes this is done and it definitely helps to get this > experience to learn the ins and outs as the protocol is developed, but it > is not required. > > As far as megaco/H.248 is concerned, I do believe something like > implementer's agreements (or profiles) will have to be worked out for > interoperability reasons for specific applications since there are so many > options and different ways of doing the same thing. Although there are > details we all don't agree on, the IP Phone profile is one attempt at doing > this for an IP Phone application. > > One thing to keep in mind is that before megaco can move to Draft Standard > in IETF, all options that don't have multiple interoperable implementations > have to be removed. > > Chip > > At 08:50 AM 3/21/00 -0500, Rosen, Brian wrote: > >I disagree with your assessment of the state of the protocol. > > > >While there have been a series of text change proposals made > >in the last few weeks, all of them have either been requests > >to clear up language, or proposals to fix some minor errors for > >unusual circumstances. In no case, AFAIK, would any of the changes > >invalidate any existing implementation by more than a very minor > >addition. There are no plans for any major changes to syntax, > >and no changes at all to semantics, unless you consider clarification > >of intent to be a semantic change. I don't understand the "transport > >syntax" part at all, unless you are thinking about the ITU work > >on ATM transport and SCTP annexes, which will not carry through to the > >IETF version on present plans. > > > >There will be an erratum published with the RFC. Together, they > >should provide a stable basis for the protocol. The document is large. > >In any such document, there are things that could use more explanation. > >While an implementor's guide has been discussed, it has not yet > >been decided if we will need one. I suspect we will. The guide will > >not, if I have anything to do with it, change the protocol at all. > >If it needs to be changed, we will have to have a new RFC. > > > >Brian > > > > > -----Original Message----- > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > > Sent: Tuesday, March 21, 2000 8:35 AM > > > To: MEGACO@standards.nortelnetworks.com > > > Subject: Proposal: explain MEGACO protocol RFC status explicitly > > > > > > > > > Hello all, > > > > > > The current MEGACO/H.248 draft, > > > draft-ietf-megaco-protocol-07.txt, > > > is still ongoing work. AFAIK the protocol is still > > > incomplete and > > > largely unimplementable. A reference implementation > > > has just been > > > started. The working group is planning to change the protocol > > > semantics and transport syntax. There would be no point in > > > publishing the document as an RFC, if this were an > > > IETF-only project > > > > > > As I have understood, publishing incomplete recommendations is > > > business as usual in ITU-T due to practical reasons. The ITU-T > > > recommendations must be approved using time-consuming formal > > > process, including a ballot. So, the finalized ITU-T > > > specification > > > actually consists of a recommendation document > > > together with an > > > Implementor's Guide correcting the errors and omissions in the > > > recommendation document. IG may contain major changes that are > > > incompatible with the published recommendation > > > document. Also, when > > > referring to a ITU-T specification, like H.323v2, people are > > > actually referring to the recommendation together with the > > > respective implementor's guide. > > > > > > The ITU-T process is (or at least should be) familiar to the > > > developers using ITU-T recommendations. However, in Internet > > > community people are expecting that the RFC is not > > > just a snapshot > > > of an on-going work. They don't anticipate that there > > > is a companion > > > document possibly changing the base protocol in every turn. > > > > > > Proposal > > > > > > I propose that the MEGACO RFC should contain a > > > paragraph explaining > > > the status of the text, ie. that the protocol will be > > > changed by an > > > Implementors' Guide published soon. The MEGACO RFC should also > > > recommend that any reference to it must also be > > > accompanied with a > > > note explaining the status of the RFC, and a reference to the > > > Implementors' Guide. > > > > > > Best regards, > > > Pekka Pesi > > > > > Support NetAid! http://www.netaid.org > -------------------------------------------------- > Chip Sharp Consulting Engineering > Cisco Systems Telco Bio-region > Reality - Love it or Leave it. > -------------------------------------------------- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 22 09:29:55 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06510 for ; Wed, 22 Mar 2000 09:29:54 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.76ACB290@standards.nortelnetworks.com>; Wed, 22 Mar 2000 9:24:46 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 98640 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 22 Mar 2000 09:23:24 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E0307C80@standards.nortelnetworks.com>; Wed, 22 Mar 2000 9:13:24 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id JAA16260; Wed, 22 Mar 2000 09:17:50 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id JAA06453; Wed, 22 Mar 2000 09:17:53 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Mar 2000 09:13:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF208B50@whq-msgusr-02.fore.com> Date: Wed, 22 Mar 2000 09:17:04 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Interop > Re: Proposal: explain MEGACO protocol RFC status ex plicitly X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM I have been planning to (help) organize early interoperability testing. There is some experience in PacketCable and ISC in testing MGCP that we can leverage. I have been looking for a "home" for this effort, and hope to have that worked out soon. I believe the first testing will NOT be part of a larger testing effort, and we will pair Megaco MGCs with Megaco MGs for testing. First tests will be done with "simple" devices - no more than a subset of the packages defined in the original document. We may have a test profile to offer well in advance of the test that will improve the probability of many MGCs and MGs to try. There will be some scripts available. It will be open to all who have devices to test. It will be "private" - no observers, just engineer to engineer. The only reports issued will be summary in nature and limited to areas of confusion or other protocol documentation issues. I'd like to hear from people implementing the protocol when they would be ready to start testing. I may have a "co-sponsor", but others are welcome if they are interested. Brian > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > Sent: Tuesday, March 21, 2000 10:27 PM > To: MEGACO@standards.nortelnetworks.com > Subject: Interop > Re: Proposal: explain MEGACO protocol RFC status > explicitly > > > G'Day all, > > Chip raises an interesting issue of interoperability tests. > The current > plans for such testing seems to me to be ambiguous at best. > > Due to the generic nature of Megaco it seems to me to be > quite difficult > to test. From what I have seen (please correct me if this isn't the > case) is that Megaco/H248 is planned to be tested as part of a larger > application test. ie. trunking gateway, IP phone etc. This to > me seems a > lot of overhead just to test the megaco protocol. It also seems to put > certain players of the interop test. ie. if I make SIP GW which have > h248 but the interop test covers IP phones how do I get my > Megaco stack > tested??? > > Are there any initiatives where something similar to the following > approach is taken? Do people see merit in this? > o The test is a test of the protocol mechanisms. > o Test between 2 boxes (PCs, workstations etc) that implement > H248 with > the necessary SW to drive the test. These boxes would be application > agnostic. > o A test package could be developed with "dummy" properties, events, > signals etc. > o A test case document which lists test cases for a good coverage test > of Megaco. These test cases could describe what should occur at dummy > event detection. > > The aim of the approach is an interop where people who intend to > implement Megaco but not in one of the proposed applications can test > there stacks without having to implement an entire application. > > If anyone has any information of the current status of Megaco interops > can they please share it on the list. > > Cheers, Christian > > > Chip Sharp wrote: > > > > As a further clarification, independent of any judgement on > megaco/H.248 in > > particular, publication of any RFC as Proposed Standard is really a > > snapshot of the development of the protocol. At the point > of publication > > of the RFC as Proposed Standard, the protocol is considered > stable enough > > to begin implementation, perform interoperability tests and > perhaps get > > some deployment experience (not necessarily in production networks). > > > > If during this process, problems are found in the protocol > and corrections > > are needed, a new RFC can be published with the corrections > while still > > remaining in Proposed Standard state. > > > > There is no requirement to implement an I-D before it moves > to Proposed > > Standard. Sometimes this is done and it definitely helps > to get this > > experience to learn the ins and outs as the protocol is > developed, but it > > is not required. > > > > As far as megaco/H.248 is concerned, I do believe something like > > implementer's agreements (or profiles) will have to be > worked out for > > interoperability reasons for specific applications since > there are so many > > options and different ways of doing the same thing. > Although there are > > details we all don't agree on, the IP Phone profile is one > attempt at doing > > this for an IP Phone application. > > > > One thing to keep in mind is that before megaco can move to > Draft Standard > > in IETF, all options that don't have multiple interoperable > implementations > > have to be removed. > > > > Chip > > > > At 08:50 AM 3/21/00 -0500, Rosen, Brian wrote: > > >I disagree with your assessment of the state of the protocol. > > > > > >While there have been a series of text change proposals made > > >in the last few weeks, all of them have either been requests > > >to clear up language, or proposals to fix some minor errors for > > >unusual circumstances. In no case, AFAIK, would any of the changes > > >invalidate any existing implementation by more than a very minor > > >addition. There are no plans for any major changes to syntax, > > >and no changes at all to semantics, unless you consider > clarification > > >of intent to be a semantic change. I don't understand the > "transport > > >syntax" part at all, unless you are thinking about the ITU work > > >on ATM transport and SCTP annexes, which will not carry > through to the > > >IETF version on present plans. > > > > > >There will be an erratum published with the RFC. Together, they > > >should provide a stable basis for the protocol. The > document is large. > > >In any such document, there are things that could use more > explanation. > > >While an implementor's guide has been discussed, it has not yet > > >been decided if we will need one. I suspect we will. The > guide will > > >not, if I have anything to do with it, change the protocol at all. > > >If it needs to be changed, we will have to have a new RFC. > > > > > >Brian > > > > > > > -----Original Message----- > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > > > Sent: Tuesday, March 21, 2000 8:35 AM > > > > To: MEGACO@standards.nortelnetworks.com > > > > Subject: Proposal: explain MEGACO protocol RFC status explicitly > > > > > > > > > > > > Hello all, > > > > > > > > The current MEGACO/H.248 draft, > > > > draft-ietf-megaco-protocol-07.txt, > > > > is still ongoing work. AFAIK the protocol is still > > > > incomplete and > > > > largely unimplementable. A reference implementation > > > > has just been > > > > started. The working group is planning to > change the protocol > > > > semantics and transport syntax. There would be > no point in > > > > publishing the document as an RFC, if this were an > > > > IETF-only project > > > > > > > > As I have understood, publishing incomplete > recommendations is > > > > business as usual in ITU-T due to practical > reasons. The ITU-T > > > > recommendations must be approved using > time-consuming formal > > > > process, including a ballot. So, the finalized ITU-T > > > > specification > > > > actually consists of a recommendation document > > > > together with an > > > > Implementor's Guide correcting the errors and > omissions in the > > > > recommendation document. IG may contain major > changes that are > > > > incompatible with the published recommendation > > > > document. Also, when > > > > referring to a ITU-T specification, like > H.323v2, people are > > > > actually referring to the recommendation > together with the > > > > respective implementor's guide. > > > > > > > > The ITU-T process is (or at least should be) > familiar to the > > > > developers using ITU-T recommendations. > However, in Internet > > > > community people are expecting that the RFC is not > > > > just a snapshot > > > > of an on-going work. They don't anticipate that there > > > > is a companion > > > > document possibly changing the base protocol in > every turn. > > > > > > > > Proposal > > > > > > > > I propose that the MEGACO RFC should contain a > > > > paragraph explaining > > > > the status of the text, ie. that the protocol will be > > > > changed by an > > > > Implementors' Guide published soon. The MEGACO > RFC should also > > > > recommend that any reference to it must also be > > > > accompanied with a > > > > note explaining the status of the RFC, and a > reference to the > > > > Implementors' Guide. > > > > > > > > Best regards, > > > > Pekka Pesi > > > > > > > > Support NetAid! http://www.netaid.org > > -------------------------------------------------- > > Chip Sharp Consulting Engineering > > Cisco Systems Telco Bio-region > > Reality - Love it or Leave it. > > -------------------------------------------------- > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 22 09:43:53 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11685 for ; Wed, 22 Mar 2000 09:43:53 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6CF6F880@standards.nortelnetworks.com>; Wed, 22 Mar 2000 9:38:48 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 98687 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 22 Mar 2000 09:37:36 -0500 Received: from mgw-x1.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.41D5DD10@standards.nortelnetworks.com>; Wed, 22 Mar 2000 9:37:36 -0500 Received: from mgw-i1.ntc.nokia.com (mgw-i1.ntc.nokia.com [131.228.118.60]) by mgw-x1.nokia.com (8.9.3/8.9.3/o) with ESMTP id QAA29492; Wed, 22 Mar 2000 16:42:08 +0200 (EET) Received: from loki.research.nokia.com (loki.research.nokia.com [172.21.33.76]) by mgw-i1.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id QAA01491; Wed, 22 Mar 2000 16:42:07 +0200 (EET) Received: from rama.research.nokia.com (IDENT:root@rama.research.nokia.com [172.21.40.44]) by loki.research.nokia.com (8.9.3/8.9.3) with ESMTP id QAA14977; Wed, 22 Mar 2000 16:42:04 +0200 (EET) Received: (from ppessi@localhost) by rama.research.nokia.com (8.9.3/8.9.1) id QAA11636; Wed, 22 Mar 2000 16:42:03 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i References: <4FBEA8857476D311A03300204840E1CF208B36@whq-msgusr-02.fore.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Message-ID: <14552.56251.575463.87983@rama.research.nokia.com> Date: Wed, 22 Mar 2000 16:42:03 +0200 Reply-To: Pekka.Pessi@nokia.com Sender: "Media Gateway Control (megaco)" From: Pekka Pessi Subject: Re: Proposal: explain MEGACO protocol RFC status explicitly X-To: Brian Rosen To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4FBEA8857476D311A03300204840E1CF208B36@whq-msgusr-02.fore.com> Content-Transfer-Encoding: 7bit Rosen, Brian writes: >I disagree with your assessment of the state of the protocol. Personally, I don't think that the protocol has really stabilized yet. Also, it is reasonable to expect that a new protocol specification contains a lot of minor errors, omissions, and other lossage. These errors will be found when 1) someone actually implements the protocol and 2) someone tries to get two independent implementations to interwork with each other. We have not done either. Sometimes the fixes can be done in a compatible way, sometimes not. >While there have been a series of text change proposals made >in the last few weeks, all of them have either been requests >to clear up language, or proposals to fix some minor errors for >unusual circumstances. Or proposals to change ABNF, or ASN.1. >In no case, AFAIK, would any of the changes >invalidate any existing implementation by more than a very minor >addition. Existing implementations? >There are no plans for any major changes to syntax, >and no changes at all to semantics, unless you consider clarification >of intent to be a semantic change. I don't understand the "transport >syntax" part at all, unless you are thinking about the ITU work >on ATM transport and SCTP annexes, which will not carry through to the >IETF version on present plans. Sorry. In ASN.1 parlance, "transport syntax" means the encoded stuff that goes on the wire. I meant both the ASN.1/BER and ABNF stuff. >There will be an erratum published with the RFC. Together, they >should provide a stable basis for the protocol. The document is large. >In any such document, there are things that could use more explanation. >While an implementor's guide has been discussed, it has not yet >been decided if we will need one. I suspect we will. The guide will >not, if I have anything to do with it, change the protocol at all. >If it needs to be changed, we will have to have a new RFC. When I browse the current spec, I think it is clear that we need an implementors' guide. In order to make this project successful in longer terms, I also think it is essentatial to clarify the rules according which the protocol will be updated and errata published. In ITU-T, a implementors' guide will usually be decided and published subsequently. It usually updates the basic version, in this case, version 1. (I don't think it is a good practice to update protocols without bumping the version number, but people in ITU seem to think otherwise.) How we do this in IETF? Do we publish the implementors' guide as another RFC, or do we replace the existing RFC with another? When we publish IG? How the work towards it is organized? I think that this is something that should be discussed with Tom. Best regards, Pekka Pessi From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 22 10:17:08 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23930 for ; Wed, 22 Mar 2000 10:17:07 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0BC82DE0@standards.nortelnetworks.com>; Wed, 22 Mar 2000 10:11:53 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 98731 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 22 Mar 2000 10:10:43 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7C815DB0@standards.nortelnetworks.com>; Wed, 22 Mar 2000 10:00:43 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id KAA22533; Wed, 22 Mar 2000 10:05:08 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id KAA17342; Wed, 22 Mar 2000 10:05:11 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Mar 2000 10:00:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF208B53@whq-msgusr-02.fore.com> Date: Wed, 22 Mar 2000 10:04:30 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Proposal: explain MEGACO protocol RFC status explicitly X-To: "Pekka.Pessi@nokia.com" To: MEGACO@STANDARDS.NORTELNETWORKS.COM There are several implementations underway that I know of. There is one group planning to release a version as a reference version. There are quite a few people who have build, and maintained parsers. When we pass IESG last call, the protocol will be published as "Proposed Standard". That is not a final specification. It is intended that further testing and specifically interoperability testing be performed. Reports of such testing must be offered before it can be advanced. It is very common that a new RFC is issued prior to advancing a "Proposed Standard". There have been some proposals to change the ASN.1 and/or ABNF. In most cases the changes are need to align one with the other. In some cases the changes are proposed to clear up ambiguity between what the text says, or intended, and what the ABNF/ASN.1 actually did. These changes, so far, have been very minor, and there are only a couple of them. I think an "Implementers Guide" is just that - information that would help an implementer create a new implementation that will interwork with others. Sometimes, an example is helpful, sometimes more text is helpful. Reports of problem areas others have encountered, etc. In my way of thinking, Implementers Guides should not change the protocol. That takes a new RFC. Brian > -----Original Message----- > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > Sent: Wednesday, March 22, 2000 9:42 AM > To: Rosen, Brian > Cc: MEGACO@standards.nortelnetworks.com > Subject: RE: Proposal: explain MEGACO protocol RFC status explicitly > > > Rosen, Brian writes: > >I disagree with your assessment of the state of the protocol. > > Personally, I don't think that the protocol has really > stabilized > yet. > > Also, it is reasonable to expect that a new protocol > specification > contains a lot of minor errors, omissions, and other > lossage. These > errors will be found when 1) someone actually implements the > protocol and 2) someone tries to get two independent > implementations > to interwork with each other. We have not done either. > Sometimes > the fixes can be done in a compatible way, sometimes not. > > >While there have been a series of text change proposals made > >in the last few weeks, all of them have either been requests > >to clear up language, or proposals to fix some minor errors for > >unusual circumstances. > > Or proposals to change ABNF, or ASN.1. > > >In no case, AFAIK, would any of the changes > >invalidate any existing implementation by more than a very minor > >addition. > > Existing implementations? > > >There are no plans for any major changes to syntax, > >and no changes at all to semantics, unless you consider clarification > >of intent to be a semantic change. I don't understand the "transport > >syntax" part at all, unless you are thinking about the ITU work > >on ATM transport and SCTP annexes, which will not carry > through to the > >IETF version on present plans. > > Sorry. In ASN.1 parlance, "transport syntax" means the > encoded stuff > that goes on the wire. I meant both the ASN.1/BER and > ABNF stuff. > > >There will be an erratum published with the RFC. Together, they > >should provide a stable basis for the protocol. The > document is large. > >In any such document, there are things that could use more > explanation. > >While an implementor's guide has been discussed, it has not yet > >been decided if we will need one. I suspect we will. The guide will > >not, if I have anything to do with it, change the protocol at all. > >If it needs to be changed, we will have to have a new RFC. > > When I browse the current spec, I think it is clear > that we need an > implementors' guide. > > In order to make this project successful in longer terms, I also > think it is essentatial to clarify the rules according which the > protocol will be updated and errata published. In ITU-T, a > implementors' guide will usually be decided and published > subsequently. It usually updates the basic version, in > this case, > version 1. (I don't think it is a good practice to > update protocols > without bumping the version number, but people in ITU > seem to think > otherwise.) > > How we do this in IETF? Do we publish the implementors' guide as > another RFC, or do we replace the existing RFC with > another? When we > publish IG? How the work towards it is organized? > > I think that this is something that should be discussed > with Tom. > > Best regards, > Pekka Pessi > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 22 16:29:56 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10351 for ; Wed, 22 Mar 2000 16:29:55 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1CAA64A0@standards.nortelnetworks.com>; Wed, 22 Mar 2000 16:24:35 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 99210 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 22 Mar 2000 16:23:29 -0500 Received: from smtprtp1.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F5691B70@standards.nortelnetworks.com>; Wed, 22 Mar 2000 16:23:29 -0500 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp1.ntcom.nortel.net; Wed, 22 Mar 2000 16:14:30 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Mar 2000 16:08:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF9442.C36951F8" Message-ID: <29400B68197CD31188830000F8CD15D343BCE1@zcard00q.ca.nortel.com> Date: Wed, 22 Mar 2000 16:08:24 -0500 Reply-To: Peter Blatherwick Sender: "Media Gateway Control (megaco)" From: Peter Blatherwick Subject: Re: Interop > Re: Proposal: explain MEGACO protocol RFC status ex plicitly 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_01BF9442.C36951F8 Content-Type: text/plain; charset="iso-8859-1" I am definitely very interested in getting some interop testing going. As part of this, I believe the WG needs to settle a few application specs to let us target something fairly constrained. I have suggested this in the past, and think it jives with what Brain, Christian, Chip and others are saying below. I also think a few such applications should be moved to standards track RFC by the WG. This would help move the industry forward by getting some applications out there relatively quickly, and provide some very concrete examples of use of the protocol, packages, profiles and so on. Others can follow through other forums later, but why not make use of the expertise and momentum we have in place now. Megaco IP Phone is definitely one such application, is written with just this in mind, and I believe is pretty much ready to roll with a few issues to settle. (Yes, I know the subset profile part remains contentious.) I believe there are a few other possible candidates, but will leave it to the authors of those to step forward. -- Peter > -----Original Message----- > From: Rosen, Brian [SMTP:brosen@FORE.COM] > Sent: 22 Mar, 2000 09:17 > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Interop > Re: Proposal: explain MEGACO protocol RFC > status ex plicitly > > I have been planning to (help) organize early interoperability > testing. There is some experience in PacketCable and ISC > in testing MGCP that we can leverage. > > I have been looking for a "home" for this effort, and hope > to have that worked out soon. > > I believe the first testing will NOT be part of a larger testing > effort, and we will pair Megaco MGCs with Megaco MGs for testing. > First tests will be done with "simple" devices - no more than > a subset of the packages defined in the original document. > We may have a test profile to offer well in advance of the test > that will improve the probability of many MGCs and MGs to try. > There will be some scripts available. > > It will be open to all who have devices to test. It will be > "private" - no observers, just engineer to engineer. The only > reports issued will be summary in nature and limited to areas > of confusion or other protocol documentation issues. > > I'd like to hear from people implementing the protocol when they > would be ready to start testing. I may have a "co-sponsor", > but others are welcome if they are interested. > > Brian > > > -----Original Message----- > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > > Sent: Tuesday, March 21, 2000 10:27 PM > > To: MEGACO@standards.nortelnetworks.com > > Subject: Interop > Re: Proposal: explain MEGACO protocol RFC status > > explicitly > > > > > > G'Day all, > > > > Chip raises an interesting issue of interoperability tests. > > The current > > plans for such testing seems to me to be ambiguous at best. > > > > Due to the generic nature of Megaco it seems to me to be > > quite difficult > > to test. From what I have seen (please correct me if this isn't the > > case) is that Megaco/H248 is planned to be tested as part of a larger > > application test. ie. trunking gateway, IP phone etc. This to > > me seems a > > lot of overhead just to test the megaco protocol. It also seems to put > > certain players of the interop test. ie. if I make SIP GW which have > > h248 but the interop test covers IP phones how do I get my > > Megaco stack > > tested??? > > > > Are there any initiatives where something similar to the following > > approach is taken? Do people see merit in this? > > o The test is a test of the protocol mechanisms. > > o Test between 2 boxes (PCs, workstations etc) that implement > > H248 with > > the necessary SW to drive the test. These boxes would be application > > agnostic. > > o A test package could be developed with "dummy" properties, events, > > signals etc. > > o A test case document which lists test cases for a good coverage test > > of Megaco. These test cases could describe what should occur at dummy > > event detection. > > > > The aim of the approach is an interop where people who intend to > > implement Megaco but not in one of the proposed applications can test > > there stacks without having to implement an entire application. > > > > If anyone has any information of the current status of Megaco interops > > can they please share it on the list. > > > > Cheers, Christian > > > > > > Chip Sharp wrote: > > > > > > As a further clarification, independent of any judgement on > > megaco/H.248 in > > > particular, publication of any RFC as Proposed Standard is really a > > > snapshot of the development of the protocol. At the point > > of publication > > > of the RFC as Proposed Standard, the protocol is considered > > stable enough > > > to begin implementation, perform interoperability tests and > > perhaps get > > > some deployment experience (not necessarily in production networks). > > > > > > If during this process, problems are found in the protocol > > and corrections > > > are needed, a new RFC can be published with the corrections > > while still > > > remaining in Proposed Standard state. > > > > > > There is no requirement to implement an I-D before it moves > > to Proposed > > > Standard. Sometimes this is done and it definitely helps > > to get this > > > experience to learn the ins and outs as the protocol is > > developed, but it > > > is not required. > > > > > > As far as megaco/H.248 is concerned, I do believe something like > > > implementer's agreements (or profiles) will have to be > > worked out for > > > interoperability reasons for specific applications since > > there are so many > > > options and different ways of doing the same thing. > > Although there are > > > details we all don't agree on, the IP Phone profile is one > > attempt at doing > > > this for an IP Phone application. > > > > > > One thing to keep in mind is that before megaco can move to > > Draft Standard > > > in IETF, all options that don't have multiple interoperable > > implementations > > > have to be removed. > > > > > > Chip > > > > > > At 08:50 AM 3/21/00 -0500, Rosen, Brian wrote: > > > >I disagree with your assessment of the state of the protocol. > > > > > > > >While there have been a series of text change proposals made > > > >in the last few weeks, all of them have either been requests > > > >to clear up language, or proposals to fix some minor errors for > > > >unusual circumstances. In no case, AFAIK, would any of the changes > > > >invalidate any existing implementation by more than a very minor > > > >addition. There are no plans for any major changes to syntax, > > > >and no changes at all to semantics, unless you consider > > clarification > > > >of intent to be a semantic change. I don't understand the > > "transport > > > >syntax" part at all, unless you are thinking about the ITU work > > > >on ATM transport and SCTP annexes, which will not carry > > through to the > > > >IETF version on present plans. > > > > > > > >There will be an erratum published with the RFC. Together, they > > > >should provide a stable basis for the protocol. The > > document is large. > > > >In any such document, there are things that could use more > > explanation. > > > >While an implementor's guide has been discussed, it has not yet > > > >been decided if we will need one. I suspect we will. The > > guide will > > > >not, if I have anything to do with it, change the protocol at all. > > > >If it needs to be changed, we will have to have a new RFC. > > > > > > > >Brian > > > > > > > > > -----Original Message----- > > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > > > > Sent: Tuesday, March 21, 2000 8:35 AM > > > > > To: MEGACO@standards.nortelnetworks.com > > > > > Subject: Proposal: explain MEGACO protocol RFC status explicitly > > > > > > > > > > > > > > > Hello all, > > > > > > > > > > The current MEGACO/H.248 draft, > > > > > draft-ietf-megaco-protocol-07.txt, > > > > > is still ongoing work. AFAIK the protocol is still > > > > > incomplete and > > > > > largely unimplementable. A reference implementation > > > > > has just been > > > > > started. The working group is planning to > > change the protocol > > > > > semantics and transport syntax. There would be > > no point in > > > > > publishing the document as an RFC, if this were an > > > > > IETF-only project > > > > > > > > > > As I have understood, publishing incomplete > > recommendations is > > > > > business as usual in ITU-T due to practical > > reasons. The ITU-T > > > > > recommendations must be approved using > > time-consuming formal > > > > > process, including a ballot. So, the finalized ITU-T > > > > > specification > > > > > actually consists of a recommendation document > > > > > together with an > > > > > Implementor's Guide correcting the errors and > > omissions in the > > > > > recommendation document. IG may contain major > > changes that are > > > > > incompatible with the published recommendation > > > > > document. Also, when > > > > > referring to a ITU-T specification, like > > H.323v2, people are > > > > > actually referring to the recommendation > > together with the > > > > > respective implementor's guide. > > > > > > > > > > The ITU-T process is (or at least should be) > > familiar to the > > > > > developers using ITU-T recommendations. > > However, in Internet > > > > > community people are expecting that the RFC is not > > > > > just a snapshot > > > > > of an on-going work. They don't anticipate that there > > > > > is a companion > > > > > document possibly changing the base protocol in > > every turn. > > > > > > > > > > Proposal > > > > > > > > > > I propose that the MEGACO RFC should contain a > > > > > paragraph explaining > > > > > the status of the text, ie. that the protocol will be > > > > > changed by an > > > > > Implementors' Guide published soon. The MEGACO > > RFC should also > > > > > recommend that any reference to it must also be > > > > > accompanied with a > > > > > note explaining the status of the RFC, and a > > reference to the > > > > > Implementors' Guide. > > > > > > > > > > Best regards, > > > > > Pekka Pesi > > > > > > > > > > > Support NetAid! http://www.netaid.org > > > -------------------------------------------------- > > > Chip Sharp Consulting Engineering > > > Cisco Systems Telco Bio-region > > > Reality - Love it or Leave it. > > > -------------------------------------------------- > > ------_=_NextPart_001_01BF9442.C36951F8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Interop > Re: Proposal: explain MEGACO protocol RFC = status ex plicitly

I am definitely very = interested in getting some interop testing going.  As part of = this, I believe the WG needs to settle a few application specs to let = us target something fairly constrained.  I have suggested this in = the past, and think it jives with what Brain, Christian, Chip and = others are saying below. 

I also think a few = such applications should be moved to standards track RFC by the = WG.  This would help move the industry forward by getting some = applications out there relatively quickly, and provide some very = concrete examples of use of the protocol, packages, profiles and so = on.  Others can follow through other forums later, but why not = make use of the expertise and momentum we have in place now.  =

Megaco IP Phone is = definitely one such application, is written with just this in mind, and = I believe is pretty much ready to roll with a few issues to = settle.  (Yes, I know the subset profile part remains = contentious.)  I believe there are a few other possible = candidates, but will leave it to the authors of those to step = forward. 

-- Peter

    -----Original Message-----
    From:   Rosen, Brian [SMTP:brosen@FORE.COM]
    Sent:   22 Mar, 2000 09:17
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: Interop > Re: Proposal: = explain MEGACO protocol RFC status ex  plicitly

    I have been planning to (help) = organize early interoperability
    testing.  There is some = experience in PacketCable and ISC
    in testing MGCP that we can = leverage.

    I have been looking for a = "home" for this effort, and hope
    to have that worked out soon.

    I believe the first testing will NOT = be part of a larger testing
    effort, and we will pair Megaco MGCs = with Megaco MGs for testing.
    First tests will be done with = "simple" devices - no more than
    a subset of the packages defined in = the original document.
    We may have a test profile to offer = well in advance of the test
    that will improve the probability of = many MGCs and MGs to try.
    There will be some scripts = available.

    It will be open to all who have = devices to test.  It will be
    "private" - no observers, = just engineer to engineer.  The only
    reports issued will be summary in = nature and limited to areas
    of confusion or other protocol = documentation issues.

    I'd like to hear from people = implementing the protocol when they
    would be ready to start testing. = I may have a "co-sponsor",
    but others are welcome if they are = interested.

    Brian

    > -----Original Message-----
    > From: Christian Groves = [mailto:Christian.Groves@ER= ICSSON.COM]
    > Sent: Tuesday, March 21, 2000 = 10:27 PM
    > To: = MEGACO@standards.nortelnetworks.com
    > Subject: Interop > Re: = Proposal: explain MEGACO protocol RFC status
    > explicitly
    >
    >
    > G'Day all,
    >
    > Chip raises an interesting issue = of interoperability tests.
    > The current
    > plans for such testing seems to = me to be ambiguous at best.
    >
    > Due to the generic nature of = Megaco it seems to me to be
    > quite difficult
    > to test. From what I have seen = (please correct me if this isn't the
    > case) is that Megaco/H248 is = planned to be tested as part of a larger
    > application test. ie. trunking = gateway, IP phone etc. This to
    > me seems a
    > lot of overhead just to test the = megaco protocol. It also seems to put
    > certain players of the interop = test. ie. if I make SIP GW which have
    > h248 but the interop test covers = IP phones how do I get my
    > Megaco stack
    > tested???
    >
    > Are there any initiatives where = something similar to the following
    > approach is taken? Do people see = merit in this?
    > o The test is a test of the = protocol mechanisms.
    > o Test between 2 boxes (PCs, = workstations etc) that implement
    > H248 with
    > the necessary SW to drive the = test. These boxes would be application
    > agnostic.
    > o A test package could be = developed with "dummy" properties, events,
    > signals etc.
    > o A test case document which = lists test cases for a good coverage test
    > of Megaco. These test cases = could describe what should occur at dummy
    > event detection.
    >
    > The aim of the approach is an = interop where people who intend to
    > implement Megaco but not in one = of the proposed applications can test
    > there stacks without having to = implement an entire application.
    >
    > If anyone has any information of = the current status of Megaco interops
    > can they please share it on the = list.
    >
    > Cheers, Christian
    >
    >
    > Chip Sharp wrote:
    > >
    > > As a further clarification, = independent of any judgement on
    > megaco/H.248 in
    > > particular, publication of = any RFC as Proposed Standard is really a
    > > snapshot of the development = of the protocol.  At the point
    > of publication
    > > of the RFC as Proposed = Standard, the protocol is considered
    > stable enough
    > > to begin implementation, = perform interoperability tests and
    > perhaps get
    > > some deployment experience = (not necessarily in production networks).
    > >
    > > If during this process, = problems are found in the protocol
    > and corrections
    > > are needed, a new RFC can = be published with the corrections
    > while still
    > > remaining in Proposed = Standard state.
    > >
    > > There is no requirement to = implement an I-D before it moves
    > to Proposed
    > > Standard.  Sometimes = this is done and it definitely helps
    > to get this
    > > experience to learn the ins = and outs as the protocol is
    > developed, but it
    > > is not required.
    > >
    > > As far as megaco/H.248 is = concerned, I do believe something like
    > > implementer's agreements = (or profiles) will have to be
    > worked out for
    > > interoperability reasons = for specific applications since
    > there are so many
    > > options and different ways = of doing the same thing.
    > Although there are
    > > details we all don't agree = on, the IP Phone profile is one
    > attempt at doing
    > > this for an IP Phone = application.
    > >
    > > One thing to keep in mind = is that before megaco can move to
    > Draft Standard
    > > in IETF, all options that = don't have multiple interoperable
    > implementations
    > > have to be removed.
    > >
    > > Chip
    > >
    > > At 08:50 AM 3/21/00 -0500, = Rosen, Brian wrote:
    > > >I disagree with your = assessment of the state of the protocol.
    > > >
    > > >While there have been a = series of text change proposals made
    > > >in the last few weeks, = all of them have either been requests
    > > >to clear up language, = or proposals to fix some minor errors for
    > > >unusual = circumstances.  In no case, AFAIK, would any of the changes
    > > >invalidate any existing = implementation by more than a very minor
    > > >addition.  There = are no plans for any major changes to syntax,
    > > >and no changes at all = to semantics, unless you consider
    > clarification
    > > >of intent to be a = semantic change.  I don't understand the
    > "transport
    > > >syntax" part at = all, unless you are thinking about the ITU work
    > > >on ATM transport and = SCTP annexes, which will not carry
    > through to the
    > > >IETF version on present = plans.
    > > >
    > > >There will be an = erratum published with the RFC.  Together, they
    > > >should provide a stable = basis for the protocol.  The
    > document is large.
    > > >In any such document, = there are things that could use more
    > explanation.
    > > >While an implementor's = guide has been discussed, it has not yet
    > > >been decided if we will = need one.  I suspect we will.  The
    > guide will
    > > >not, if I have anything = to do with it, change the protocol at all.
    > > >If it needs to be = changed, we will have to have a new RFC.
    > > >
    > > >Brian
    > > >
    > > > > -----Original = Message-----
    > > > > From: Pekka Pessi = [mailto:Pekka.Pessi@nokia.com]
    > > > > Sent: Tuesday, = March 21, 2000 8:35 AM
    > > > > To: = MEGACO@standards.nortelnetworks.com
    > > > > Subject: = Proposal: explain MEGACO protocol RFC status explicitly
    > > > >
    > > > >
    > > > = >         Hello all,
    > > > >
    > > > = >         The current = MEGACO/H.248 draft,
    > > > > = draft-ietf-megaco-protocol-07.txt,
    > > > = >         is still ongoing = work. AFAIK the protocol is still
    > > > > incomplete = and
    > > > >   &= nbsp;     largely unimplementable. A reference = implementation
    > > > > has just = been
    > > > = >         started.  The = working group is planning to
    > change the protocol
    > > > = >         semantics and = transport syntax. There would be
    > no point in
    > > > = >         publishing the = document as an RFC, if this were an
    > > > > IETF-only = project
    > > > >
    > > > = >         As I have = understood, publishing incomplete
    > recommendations is
    > > > = >         business as usual = in ITU-T due to practical
    > reasons. The ITU-T
    > > > = >         recommendations = must be approved using
    > time-consuming formal
    > > > = >         process, including = a ballot. So, the finalized ITU-T
    > > > > = specification
    > > > = >         actually consists = of a recommendation document
    > > > > together with = an
    > > > = >         Implementor's = Guide correcting the errors and
    > omissions in the
    > > > = >         recommendation = document. IG may contain major
    > changes that are
    > > > = >         incompatible with = the published recommendation
    > > > > document.  = Also, when
    > > > = >         referring to a = ITU-T specification, like
    > H.323v2, people are
    > > > = >         actually referring = to the recommendation
    > together with the
    > > > = >         respective = implementor's guide.
    > > > >
    > > > = >         The ITU-T process = is (or at least should be)
    > familiar to the
    > > > = >         developers using = ITU-T recommendations.
    > However, in Internet
    > > > = >         community people = are expecting that the RFC is not
    > > > > just a = snapshot
    > > > = >         of an on-going = work. They don't anticipate that there
    > > > > is a = companion
    > > > = >         document possibly = changing the base protocol in
    > every turn.
    > > > >
    > > > > Proposal
    > > > >
    > > > = >         I propose that the = MEGACO RFC should contain a
    > > > > paragraph = explaining
    > > > = >         the status of the = text, ie. that the protocol will be
    > > > > changed by = an
    > > > = >         Implementors' = Guide published soon. The MEGACO
    > RFC should also
    > > > = >         recommend that any = reference to it must also be
    > > > > accompanied with = a
    > > > = >         note explaining = the status of the RFC, and a
    > reference to the
    > > > = >         Implementors' = Guide.
    > > > >
    > > > = >         Best = regards,
    > > > = >           &n= bsp;           &n= bsp;           &n= bsp;     Pekka Pesi
    > > > >
    > >
    > > Support = NetAid!  http://www.netaid.org
    > > = --------------------------------------------------
    > > Chip = Sharp           &= nbsp;     Consulting Engineering
    > > Cisco = Systems           = ;   Telco Bio-region
    > > Reality - Love it or Leave = it.
    > > = --------------------------------------------------
    >

------_=_NextPart_001_01BF9442.C36951F8-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 22 17:31:38 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02430 for ; Wed, 22 Mar 2000 17:31:38 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C8639980@standards.nortelnetworks.com>; Wed, 22 Mar 2000 17:26:39 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 99262 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 22 Mar 2000 17:25:34 -0500 Received: from alpha.telecom-co.net (200.21.27.100) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3B8D7B30@standards.nortelnetworks.com>; Wed, 22 Mar 2000 17:15:33 -0500 Received: from LQUIROGA ([200.21.27.13]) by alpha.telecom-co.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id HL9FSTJN; Wed, 22 Mar 2000 17:24:26 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01BF9422.EC6F9DC0" 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: <003601bf944c$d9226ac0$0d1b15c8@alpha.telecomco.net> Date: Wed, 22 Mar 2000 17:20:30 -0500 Reply-To: Luis Carlos Q Sender: "Media Gateway Control (megaco)" From: Luis Carlos Q Subject: Implementation Megaco/H248 Questions To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0033_01BF9422.EC6F9DC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Everybody: I=B4m making a "little" implementation of the Megaco/H248 Protocol in = C++=20 Program language and I have some questions about this implementation. - Is the sysntax that ASN.1 explain the only form to make an=20 implementation of the protocol? - Which is the relationship between the packages, the descriptors and = the commands into the protocol?=20 - Which is the form of implement the packages with an oriented object = programming language? - In the ASN.1 syntax specification i can found some terms or structures = that the recomendation Megaco/H248 never use to describe or define=20 anything. For examples : "StreamID" or another like "PckgName"..=20 What is the meaning of this terms or its use into the Protocol?? - Which are the main structures (into the ASN syntax specification) that = the Protocol use to make a call between two Terminations? - Where I Can found more information about the Protocol and the=20 best/simple form to make my implementation better with this Program=20 Language(C++)? - Who was make a prototype of the protocol with an oriented object=20 programming language before? ------=_NextPart_000_0033_01BF9422.EC6F9DC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello Everybody:
 
I=B4m making a "little" implementation = of the=20 Megaco/H248 Protocol in C++
Program language and  I have = some=20 questions about this implementation.
 
- Is the sysntax that ASN.1 explain the = only form=20 to make an
implementation of the = protocol?
 
- Which is the relationship between the = packages,=20 the descriptors and the commands into the protocol?
 
- Which is the form of implement the = packages with=20 an oriented object programming language?
 
- In the ASN.1 syntax specification i = can found=20 some terms or structures
that the recomendation Megaco/H248 = never use to=20 describe or define
anything. For examples :  = "StreamID" or=20 another like "PckgName"..
What is the meaning of this terms or = its use into=20 the Protocol??
 
- Which are the main structures (into = the ASN=20 syntax specification) that
the Protocol use to make a call between = two=20 Terminations?
 
- Where I Can found more information = about the=20 Protocol and the
best/simple form to make  my = implementation=20 better with this Program
Language(C++)?
 
- Who was make a prototype of the = protocol with an=20 oriented object
programming language=20 before?
------=_NextPart_000_0033_01BF9422.EC6F9DC0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 22 22:42:10 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27534 for ; Wed, 22 Mar 2000 22:42:10 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.23F74C80@standards.nortelnetworks.com>; Wed, 22 Mar 2000 22:37:01 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 99516 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 22 Mar 2000 22:35:42 -0500 Received: from ish7.ericsson.com.au (203.61.155.111) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8EB12570@standards.nortelnetworks.com>; Wed, 22 Mar 2000 22:25:41 -0500 Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.1) with ESMTP id OAA12261; Thu, 23 Mar 2000 14:29:14 +1100 (EST) Received: from mcsi00.epa.ericsson.se (mcsi00 [146.11.8.201]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id OAA14488; Thu, 23 Mar 2000 14:29:54 +1100 (EST) Received: from ericsson.com (mc2dh6.epa.ericsson.se [146.11.87.6]) by mcsi00.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA08572; Thu, 23 Mar 2000 14:29:11 +1100 (EST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38D98F8F.35A2C799@ericsson.com> Date: Thu, 23 Mar 2000 14:29:19 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: V16 review - Editorial comments X-To: Nancy-M Greene To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Nancy, Please see my comments marked [CHG]. Cheers, Christian Nancy-M Greene wrote: > > Brian, John, > I believe each of the following is an editorial change to V16. You > have both seen most of these already, and commented on them - I am > posting them to the megaco list this time, with the proposed > resolutions. Please comment! > > 1- Section 7.1.1 Specifying Parameters > Issue: para. starting with "Unspecified mandatory parameters > (i.e. mandatory parameters not specified in a descriptor) result > in the command responder retaining the previous value for that > parameter." > > Comment: It seems that this section applies only to mandatory fields > in > Local and Remote descriptors (see section 7.1.8). For example, when > a mandatory parameter is unspecified in the Local descriptor, > then it retains the value it already has. But, a mandatory parameter > in a ServiceChange HAS to be there I would think. For example, the > ServiceChangeMethod descriptor is mandatory, and must > always be present. > > Proposal: Preface the quoted sentence in 7.1.1 with "For Local and > Remote Descriptors, unspecified mandatory parameters (i.e. mandatory > parameters not specified in a descriptor) result in the ...." > > 2- Section 7.1.6 Stream Descriptor > Issue: last sentence of first para, "A stream is deleted by > setting empty Local and Remote descriptors for the stream with > ReserveGroup and ReserveValue in LocalControl set to "false" on > all terminations in the context that previously supported that > stream." > > Comment: We don't have false or true in the ABNF, only "ON/OFF". The > text uses both true/false, and on/off. > > Proposal: Make no changes to the text. Just add this comment: > "ON = true, and OFF = false" to the ABNF. [CHG] OK > > 3- Section 7.1.7 LocalControl Descriptor - ReserveGroup/ReserveValue > Issue: There is no explanation as to what ReserveValue and > ReserveGroup mean. > > Proposal: Add text something like the following: > "In order to state that one session description is to be selected > out of a list, ReserveGroup is set to "false". If resources for all > session descriptions are to be reserved, ReserveGroup is set > to "true". In order to state that a parameter with a list of values, > e.g. multiple rtp payload types, requires one value is to be > selected from the list, ReserveValue is set to "false". If resources > for all values are to be reserved, ReserveValue is set to "true". > In other words, overspecifying by giving a list of values can happen > independently at the session description level and at the parameter > level. " [CHG] I don't think this is necessary. The text currently states: "The boolean-valued Reserve properties, ReserveValue and ReserveGroup" and then it follows in the next 2 paragraphs about what to do. The terms value and groups are used in other sections. This isn't an error at best its something for a possible implementors guide. > > 4- Section 7.1.9 Events Descriptor - eventDM > Issue: eventDM is not mentioned in this section while it is part of > the > eventsDescriptor syntax. > > Proposal: Add this sentence: > "If a digit map is required in the EventsDescriptor, EventDM is used > to carry either the name or the value of the digit map. See > section 7.1.14." > > 5- Section 7.1.11 Signals Descriptor > Issue: setting of the signal list type > > Proposal: Add the following to section 7.1.11: > * on/off in signal list > -> it must be the last element, and signal list type must be > on/off > * timeout in signal list (and NO on/off signals in the list) > -> signal list type must be timeout > * only brief signals in signal list > -> signal list type defaults to brief. [CHG] Isn't this in the determined draft? 2nd paragraph after list. > > 6- Section 7.1.12 Audit Descriptor, and also auditItem in the ABNF > Issue: the last entry in the table is "EventBuffer". auditItem in the > ABNF > does not qualify it either which is incorrect. > > Proposal: Change "EventBuffer" to "EventBuffer Descriptor" in both > section 7.1.12 > and in the ABNF. > > 7- Section 7.1.13 ServiceChangeDescriptor > Issue: Extension is not part of the enumeration > > Comment: Is ServiceChangeDescriptor supposed to be extendable or not? > The ABNF still has an extension parameter in it. [CHG] I don't like the extension parameter but we do have it. See 7.2.8 no.7 in the list. And the text in 7.2.8 "The optional Extension parameter may contain any value whose meaning is mutually understood by the MG and MGC." > > 8- Section 7.1.18 Topology Descriptor > Issue: para starting with "(T1,T2, bothway) means that .... > loopbacks are created by setting the TerminationMode." > > Comment: We don't have TerminationMode any more. > > Proposal: change it to read: > "...loopbacks are created by setting the StreamMode property to > LoopBack > in the LocalControlDescriptor." [CHG] Perhaps we can just delete the text after the ";"? StreamMode = Loopback is in 7.1.7 > > 9- 7.2.5 Audit Value > Issue "W-" and "O-" > Comment: Text does not describe that wildcarded response > is qualified by "W-". Also, no text explaining that > optional commands are qualified by "O-". > > Proposal: in section 7.2.5, add the following: > "The wildcard response option (see section 6.2.2) is particularly > useful > to limit the size of a n audit value command which uses a wildcard > terminationId. In ASN.1 encoding (Annex A), the flag "wildcardReturn" > is set on a command, and in ABNF (Annex B), the command is qualified > by the "W-" option." [CHG] Sect 6.2.2 already covers much of this. I don't see a need to repeat the information in 7.2.5. 6.2.2 even recommends that this is useful for audit. > > Also, in section 8, add the following: > "In ASN.1 encoding, the flag "optional" is set on a command, and in > the > ABNF, the command is qualified with the "O-" option." > > 10- Section 7.2.6 AuditCapabilities > Issue: AuditCapability API > > Comment: same as in 9-Section 7.2.5 > > Proposal: Add same sentences as above, to this section. > [CHG] See my comment on 7.2.5 > 11- Section 7.2.6 AuditCapabilities - DigitMap and Packages > Issue: DigitMap and Packages in the ABNF > > Comment: The ABNF allows DigitMap and Packages > in the return of AuditCapability. The text says no. Need to > add a comment in the ABNF that explains this. > > Proposal: Add the following comment to the ABNF: > "DigitMap and Packages are not permitted to be part of > AuditCapabilities" > > 12- ANNEX B: signalListParm > Issue: signalListParm = signalRequest > > Comment: This is redundant. > > Proposal: in the ABNF, signalRequest should replace > signalListParm in signalList. > > 13- ANNEX B:digitMapValue > Issue: digitMapDescriptor = DigitMapToken EQUAL digitMapName > ( LBRKT digitMapValue RBRKT ) > > Comment: error with the round brackets > > Proposal: it should be > digitMapDescriptor = DigitMapToken EQUAL digitMapName > [ LBRKT digitMapValue RBRKT ] > > 14- ANNEX B: version token > Issue: VersionToken is missing in the ABNF. > > Proposal: Add VersionToken = ("Version" / "V") > > Nancy & Abdallah > > -------------------------------------------------------------------------- > > Nancy M. Greene > Internet & Service Provider Networks, Nortel Networks > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 22 23:18:04 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10125 for ; Wed, 22 Mar 2000 23:18:04 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2D42CEE0@standards.nortelnetworks.com>; Wed, 22 Mar 2000 23:13:04 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 99556 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 22 Mar 2000 23:11:54 -0500 Received: from ish7.ericsson.com.au (203.61.155.111) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9D2574D0@standards.nortelnetworks.com>; Wed, 22 Mar 2000 23:01:53 -0500 Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.1) with ESMTP id PAA15100; Thu, 23 Mar 2000 15:04:55 +1100 (EST) Received: from mcsi00.epa.ericsson.se (mcsi00 [146.11.8.201]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id PAA19772; Thu, 23 Mar 2000 15:05:35 +1100 (EST) Received: from ericsson.com (mc2dh6.epa.ericsson.se [146.11.87.6]) by mcsi00.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id PAA10039; Thu, 23 Mar 2000 15:04:51 +1100 (EST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------24FEB7C3E8ED256CD0C78A04" Message-ID: <38D997EB.70589895@ericsson.com> Date: Thu, 23 Mar 2000 15:04:59 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: [Fwd: I-D ACTION:draft-brown-supplpkgs-00.txt] X-To: Michael Brown To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------24FEB7C3E8ED256CD0C78A04 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit G'Day Mike, A couple of comments on the packages draft. Comments: o General : No tag numbers for the binary coding. o The use of International terminology or a A glossary of North American to International terms would be good. ie. wink = hookflash o Sect 3.3 Events : "Events are defined as in this package for the signals" what does this mean? o 4.1 Events - Seize and Answer do the same thing according to the description. Cheers, Christian -------- Original Message -------- Subject: I-D ACTION:draft-brown-supplpkgs-00.txt Date: Sat, 18 Mar 2000 00:22:24 +1100 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Supplemental Packages for Megaco/H.248 Author(s) : C. Brown, K. Chapman, K. Boyle Filename : draft-brown-supplpkgs-00.txt Pages : Date : 16-Mar-00 This document provides proposed definitions for several supplemental packages for Megaco/H.248. These packages address support of functionality for basic and enhanced telephony services, and PSTN Per Trunk Signaling (PTS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-brown-supplpkgs-00.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-brown-supplpkgs-00.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-brown-supplpkgs-00.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. --------------24FEB7C3E8ED256CD0C78A04 Content-Type: message/rfc822; name="nsmailR0.TMP" Content-Disposition: inline; filename="nsmailR0.TMP" Subject: Date: Mon, 20 Mar 2000 09:57:13 +1100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01BF9040.BC8A649A" ------_=_NextPart_002_01BF9040.BC8A649A Content-Type: text/plain ------_=_NextPart_002_01BF9040.BC8A649A Content-Type: application/octet-stream; name="ATT13319" Content-Disposition: attachment; filename="ATT13319" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000316144455.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-brown-supplpkgs-00.txt ------_=_NextPart_002_01BF9040.BC8A649A Content-Type: message/external-body; site="internet-drafts"; dir="draft-brown-supplpkgs-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01BF9040.BC8A649A-- --------------24FEB7C3E8ED256CD0C78A04-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 23 01:15:26 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24492 for ; Thu, 23 Mar 2000 01:15:25 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8F8016C0@standards.nortelnetworks.com>; Thu, 23 Mar 2000 1:10:21 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 99712 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 23 Mar 2000 01:08:31 -0500 Received: from ish7.ericsson.com.au (203.61.155.111) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E7AC7C50@standards.nortelnetworks.com>; Thu, 23 Mar 2000 0:58:30 -0500 Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.1) with ESMTP id RAA24164; Thu, 23 Mar 2000 17:00:54 +1100 (EST) Received: from mcsi00.epa.ericsson.se (mcsi00 [146.11.8.201]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id RAA05361; Thu, 23 Mar 2000 17:01:33 +1100 (EST) Received: from ericsson.com (mc2dh6.epa.ericsson.se [146.11.87.6]) by mcsi00.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id RAA12703; Thu, 23 Mar 2000 17:00:47 +1100 (EST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF208B50@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38D9B315.C51C934@ericsson.com> Date: Thu, 23 Mar 2000 17:00:53 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Interop > Re: Proposal: explain MEGACO protocol RFC status explicitly X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Brian, Thanks for the update. Can you elaborate on the "home" of this effort? I know you've done some work in MSF on this. Can you provide some info to the list if you have more details of what is to be tested and what the current plans are? Is it necessary to organise a "home" for this effort? Sigtran it seems are doing a protocol interop test without having to go to another forum. Interested parties are getting together. Perhaps someone who participates in the Sigtran interop can comment? Perhaps we could do something similar for Megaco? I'm glad that the first step with not be part of a larger effort and will be done on simple devices. The question is what sort of devices and what packages? I've envisaged that the test could be done as you say between Megaco MGC and Megaco MG and would be agnostic of the application and many packages. I saw that we test the root package as it has protocol specific information and perhaps a specifically developed test package that has a number of properties, signals, events, statistics labelled in a very generic way. I didn't see that we would do a simple IP phone or trunking GW interop. After all we just need to test the Megaco mechanisms. A test profile containing test cases and scripts could then be defined to test the various protocol mechanism employed to relay the properties, signals, events and statistics. We can worry about format and reporting of the interop event when we get closer to it. Cheers, Christian "Rosen, Brian" wrote: > > I have been planning to (help) organize early interoperability > testing. There is some experience in PacketCable and ISC > in testing MGCP that we can leverage. > > I have been looking for a "home" for this effort, and hope > to have that worked out soon. > > I believe the first testing will NOT be part of a larger testing > effort, and we will pair Megaco MGCs with Megaco MGs for testing. > First tests will be done with "simple" devices - no more than > a subset of the packages defined in the original document. > We may have a test profile to offer well in advance of the test > that will improve the probability of many MGCs and MGs to try. > There will be some scripts available. > > It will be open to all who have devices to test. It will be > "private" - no observers, just engineer to engineer. The only > reports issued will be summary in nature and limited to areas > of confusion or other protocol documentation issues. > > I'd like to hear from people implementing the protocol when they > would be ready to start testing. I may have a "co-sponsor", > but others are welcome if they are interested. > > Brian > > > -----Original Message----- > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > > Sent: Tuesday, March 21, 2000 10:27 PM > > To: MEGACO@standards.nortelnetworks.com > > Subject: Interop > Re: Proposal: explain MEGACO protocol RFC status > > explicitly > > > > > > G'Day all, > > > > Chip raises an interesting issue of interoperability tests. > > The current > > plans for such testing seems to me to be ambiguous at best. > > > > Due to the generic nature of Megaco it seems to me to be > > quite difficult > > to test. From what I have seen (please correct me if this isn't the > > case) is that Megaco/H248 is planned to be tested as part of a larger > > application test. ie. trunking gateway, IP phone etc. This to > > me seems a > > lot of overhead just to test the megaco protocol. It also seems to put > > certain players of the interop test. ie. if I make SIP GW which have > > h248 but the interop test covers IP phones how do I get my > > Megaco stack > > tested??? > > > > Are there any initiatives where something similar to the following > > approach is taken? Do people see merit in this? > > o The test is a test of the protocol mechanisms. > > o Test between 2 boxes (PCs, workstations etc) that implement > > H248 with > > the necessary SW to drive the test. These boxes would be application > > agnostic. > > o A test package could be developed with "dummy" properties, events, > > signals etc. > > o A test case document which lists test cases for a good coverage test > > of Megaco. These test cases could describe what should occur at dummy > > event detection. > > > > The aim of the approach is an interop where people who intend to > > implement Megaco but not in one of the proposed applications can test > > there stacks without having to implement an entire application. > > > > If anyone has any information of the current status of Megaco interops > > can they please share it on the list. > > > > Cheers, Christian > > > > > > Chip Sharp wrote: > > > > > > As a further clarification, independent of any judgement on > > megaco/H.248 in > > > particular, publication of any RFC as Proposed Standard is really a > > > snapshot of the development of the protocol. At the point > > of publication > > > of the RFC as Proposed Standard, the protocol is considered > > stable enough > > > to begin implementation, perform interoperability tests and > > perhaps get > > > some deployment experience (not necessarily in production networks). > > > > > > If during this process, problems are found in the protocol > > and corrections > > > are needed, a new RFC can be published with the corrections > > while still > > > remaining in Proposed Standard state. > > > > > > There is no requirement to implement an I-D before it moves > > to Proposed > > > Standard. Sometimes this is done and it definitely helps > > to get this > > > experience to learn the ins and outs as the protocol is > > developed, but it > > > is not required. > > > > > > As far as megaco/H.248 is concerned, I do believe something like > > > implementer's agreements (or profiles) will have to be > > worked out for > > > interoperability reasons for specific applications since > > there are so many > > > options and different ways of doing the same thing. > > Although there are > > > details we all don't agree on, the IP Phone profile is one > > attempt at doing > > > this for an IP Phone application. > > > > > > One thing to keep in mind is that before megaco can move to > > Draft Standard > > > in IETF, all options that don't have multiple interoperable > > implementations > > > have to be removed. > > > > > > Chip > > > > > > At 08:50 AM 3/21/00 -0500, Rosen, Brian wrote: > > > >I disagree with your assessment of the state of the protocol. > > > > > > > >While there have been a series of text change proposals made > > > >in the last few weeks, all of them have either been requests > > > >to clear up language, or proposals to fix some minor errors for > > > >unusual circumstances. In no case, AFAIK, would any of the changes > > > >invalidate any existing implementation by more than a very minor > > > >addition. There are no plans for any major changes to syntax, > > > >and no changes at all to semantics, unless you consider > > clarification > > > >of intent to be a semantic change. I don't understand the > > "transport > > > >syntax" part at all, unless you are thinking about the ITU work > > > >on ATM transport and SCTP annexes, which will not carry > > through to the > > > >IETF version on present plans. > > > > > > > >There will be an erratum published with the RFC. Together, they > > > >should provide a stable basis for the protocol. The > > document is large. > > > >In any such document, there are things that could use more > > explanation. > > > >While an implementor's guide has been discussed, it has not yet > > > >been decided if we will need one. I suspect we will. The > > guide will > > > >not, if I have anything to do with it, change the protocol at all. > > > >If it needs to be changed, we will have to have a new RFC. > > > > > > > >Brian > > > > > > > > > -----Original Message----- > > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > > > > Sent: Tuesday, March 21, 2000 8:35 AM > > > > > To: MEGACO@standards.nortelnetworks.com > > > > > Subject: Proposal: explain MEGACO protocol RFC status explicitly > > > > > > > > > > > > > > > Hello all, > > > > > > > > > > The current MEGACO/H.248 draft, > > > > > draft-ietf-megaco-protocol-07.txt, > > > > > is still ongoing work. AFAIK the protocol is still > > > > > incomplete and > > > > > largely unimplementable. A reference implementation > > > > > has just been > > > > > started. The working group is planning to > > change the protocol > > > > > semantics and transport syntax. There would be > > no point in > > > > > publishing the document as an RFC, if this were an > > > > > IETF-only project > > > > > > > > > > As I have understood, publishing incomplete > > recommendations is > > > > > business as usual in ITU-T due to practical > > reasons. The ITU-T > > > > > recommendations must be approved using > > time-consuming formal > > > > > process, including a ballot. So, the finalized ITU-T > > > > > specification > > > > > actually consists of a recommendation document > > > > > together with an > > > > > Implementor's Guide correcting the errors and > > omissions in the > > > > > recommendation document. IG may contain major > > changes that are > > > > > incompatible with the published recommendation > > > > > document. Also, when > > > > > referring to a ITU-T specification, like > > H.323v2, people are > > > > > actually referring to the recommendation > > together with the > > > > > respective implementor's guide. > > > > > > > > > > The ITU-T process is (or at least should be) > > familiar to the > > > > > developers using ITU-T recommendations. > > However, in Internet > > > > > community people are expecting that the RFC is not > > > > > just a snapshot > > > > > of an on-going work. They don't anticipate that there > > > > > is a companion > > > > > document possibly changing the base protocol in > > every turn. > > > > > > > > > > Proposal > > > > > > > > > > I propose that the MEGACO RFC should contain a > > > > > paragraph explaining > > > > > the status of the text, ie. that the protocol will be > > > > > changed by an > > > > > Implementors' Guide published soon. The MEGACO > > RFC should also > > > > > recommend that any reference to it must also be > > > > > accompanied with a > > > > > note explaining the status of the RFC, and a > > reference to the > > > > > Implementors' Guide. > > > > > > > > > > Best regards, > > > > > Pekka Pesi > > > > > > > > > > > Support NetAid! http://www.netaid.org > > > -------------------------------------------------- > > > Chip Sharp Consulting Engineering > > > Cisco Systems Telco Bio-region > > > Reality - Love it or Leave it. > > > -------------------------------------------------- > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 23 09:25:09 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22165 for ; Thu, 23 Mar 2000 09:25:08 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EB891770@standards.nortelnetworks.com>; Thu, 23 Mar 2000 9:19:41 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 99949 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 23 Mar 2000 09:19:23 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E04DE0C0@standards.nortelnetworks.com>; Thu, 23 Mar 2000 9:19:22 -0500 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Thu, 23 Mar 2000 08:06:50 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Mar 2000 08:06:25 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF94D0.F8AFEF32" Message-ID: <29400B68197CD31188830000F8CD15D343BCE7@zcard00q.ca.nortel.com> Date: Thu, 23 Mar 2000 08:06:22 -0600 Reply-To: Peter Blatherwick Sender: "Media Gateway Control (megaco)" From: Peter Blatherwick Subject: Re: Interop > Re: Proposal: explain MEGACO protocol RFC status e xplicitly X-To: Christian Groves 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_01BF94D0.F8AFEF32 Content-Type: text/plain; charset="iso-8859-1" I like the idea of a test suite. It would allow us to quickly verify the basic mechanics in an agnostic way. This would not test the specific packages, which of course also need to be interoped, and would not be a "test in practice". Of course designing the suite would take some time. I still believe that deciding some simple, real, applications would be a VERY good step as well, real soon. Test suite would be an initial step only in my mind. Real applications is what we're trying to get to after all, and we'll learn a lot more about the practical aspects through these. My 0.02. (How much is that in Oz dollars, converted from Canadian?) -- Peter > -----Original Message----- > From: Christian Groves [SMTP:Christian.Groves@ERICSSON.COM] > Sent: 23 Mar, 2000 01:01 > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Interop > Re: Proposal: explain MEGACO protocol RFC > status explicitly > > G'Day Brian, > > Thanks for the update. Can you elaborate on the "home" of this effort? I > know you've done some work in MSF on this. Can you provide some info to > the list if you have more details of what is to be tested and what the > current plans are? > > Is it necessary to organise a "home" for this effort? Sigtran it seems > are doing a protocol interop test without having to go to another forum. > Interested parties are getting together. Perhaps someone who > participates in the Sigtran interop can comment? Perhaps we could do > something similar for Megaco? > > I'm glad that the first step with not be part of a larger effort and > will be done on simple devices. The question is what sort of devices and > what packages? > > I've envisaged that the test could be done as you say between Megaco MGC > and Megaco MG and would be agnostic of the application and many > packages. I saw that we test the root package as it has protocol > specific information and perhaps a specifically developed test package > that has a number of properties, signals, events, statistics labelled in > a very generic way. I didn't see that we would do a simple IP phone or > trunking GW interop. After all we just need to test the Megaco > mechanisms. > > A test profile containing test cases and scripts could then be defined > to test the various protocol mechanism employed to relay the properties, > signals, events and statistics. > > We can worry about format and reporting of the interop event when we get > closer to it. > > Cheers, Christian > > "Rosen, Brian" wrote: > > > > I have been planning to (help) organize early interoperability > > testing. There is some experience in PacketCable and ISC > > in testing MGCP that we can leverage. > > > > I have been looking for a "home" for this effort, and hope > > to have that worked out soon. > > > > I believe the first testing will NOT be part of a larger testing > > effort, and we will pair Megaco MGCs with Megaco MGs for testing. > > First tests will be done with "simple" devices - no more than > > a subset of the packages defined in the original document. > > We may have a test profile to offer well in advance of the test > > that will improve the probability of many MGCs and MGs to try. > > There will be some scripts available. > > > > It will be open to all who have devices to test. It will be > > "private" - no observers, just engineer to engineer. The only > > reports issued will be summary in nature and limited to areas > > of confusion or other protocol documentation issues. > > > > I'd like to hear from people implementing the protocol when they > > would be ready to start testing. I may have a "co-sponsor", > > but others are welcome if they are interested. > > > > Brian > > > > > -----Original Message----- > > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > > > Sent: Tuesday, March 21, 2000 10:27 PM > > > To: MEGACO@standards.nortelnetworks.com > > > Subject: Interop > Re: Proposal: explain MEGACO protocol RFC status > > > explicitly > > > > > > > > > G'Day all, > > > > > > Chip raises an interesting issue of interoperability tests. > > > The current > > > plans for such testing seems to me to be ambiguous at best. > > > > > > Due to the generic nature of Megaco it seems to me to be > > > quite difficult > > > to test. From what I have seen (please correct me if this isn't the > > > case) is that Megaco/H248 is planned to be tested as part of a larger > > > application test. ie. trunking gateway, IP phone etc. This to > > > me seems a > > > lot of overhead just to test the megaco protocol. It also seems to put > > > certain players of the interop test. ie. if I make SIP GW which have > > > h248 but the interop test covers IP phones how do I get my > > > Megaco stack > > > tested??? > > > > > > Are there any initiatives where something similar to the following > > > approach is taken? Do people see merit in this? > > > o The test is a test of the protocol mechanisms. > > > o Test between 2 boxes (PCs, workstations etc) that implement > > > H248 with > > > the necessary SW to drive the test. These boxes would be application > > > agnostic. > > > o A test package could be developed with "dummy" properties, events, > > > signals etc. > > > o A test case document which lists test cases for a good coverage test > > > of Megaco. These test cases could describe what should occur at dummy > > > event detection. > > > > > > The aim of the approach is an interop where people who intend to > > > implement Megaco but not in one of the proposed applications can test > > > there stacks without having to implement an entire application. > > > > > > If anyone has any information of the current status of Megaco interops > > > can they please share it on the list. > > > > > > Cheers, Christian > > > > > > > > > Chip Sharp wrote: > > > > > > > > As a further clarification, independent of any judgement on > > > megaco/H.248 in > > > > particular, publication of any RFC as Proposed Standard is really a > > > > snapshot of the development of the protocol. At the point > > > of publication > > > > of the RFC as Proposed Standard, the protocol is considered > > > stable enough > > > > to begin implementation, perform interoperability tests and > > > perhaps get > > > > some deployment experience (not necessarily in production networks). > > > > > > > > If during this process, problems are found in the protocol > > > and corrections > > > > are needed, a new RFC can be published with the corrections > > > while still > > > > remaining in Proposed Standard state. > > > > > > > > There is no requirement to implement an I-D before it moves > > > to Proposed > > > > Standard. Sometimes this is done and it definitely helps > > > to get this > > > > experience to learn the ins and outs as the protocol is > > > developed, but it > > > > is not required. > > > > > > > > As far as megaco/H.248 is concerned, I do believe something like > > > > implementer's agreements (or profiles) will have to be > > > worked out for > > > > interoperability reasons for specific applications since > > > there are so many > > > > options and different ways of doing the same thing. > > > Although there are > > > > details we all don't agree on, the IP Phone profile is one > > > attempt at doing > > > > this for an IP Phone application. > > > > > > > > One thing to keep in mind is that before megaco can move to > > > Draft Standard > > > > in IETF, all options that don't have multiple interoperable > > > implementations > > > > have to be removed. > > > > > > > > Chip > > > > > > > > At 08:50 AM 3/21/00 -0500, Rosen, Brian wrote: > > > > >I disagree with your assessment of the state of the protocol. > > > > > > > > > >While there have been a series of text change proposals made > > > > >in the last few weeks, all of them have either been requests > > > > >to clear up language, or proposals to fix some minor errors for > > > > >unusual circumstances. In no case, AFAIK, would any of the changes > > > > >invalidate any existing implementation by more than a very minor > > > > >addition. There are no plans for any major changes to syntax, > > > > >and no changes at all to semantics, unless you consider > > > clarification > > > > >of intent to be a semantic change. I don't understand the > > > "transport > > > > >syntax" part at all, unless you are thinking about the ITU work > > > > >on ATM transport and SCTP annexes, which will not carry > > > through to the > > > > >IETF version on present plans. > > > > > > > > > >There will be an erratum published with the RFC. Together, they > > > > >should provide a stable basis for the protocol. The > > > document is large. > > > > >In any such document, there are things that could use more > > > explanation. > > > > >While an implementor's guide has been discussed, it has not yet > > > > >been decided if we will need one. I suspect we will. The > > > guide will > > > > >not, if I have anything to do with it, change the protocol at all. > > > > >If it needs to be changed, we will have to have a new RFC. > > > > > > > > > >Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > > > > > Sent: Tuesday, March 21, 2000 8:35 AM > > > > > > To: MEGACO@standards.nortelnetworks.com > > > > > > Subject: Proposal: explain MEGACO protocol RFC status explicitly > > > > > > > > > > > > > > > > > > Hello all, > > > > > > > > > > > > The current MEGACO/H.248 draft, > > > > > > draft-ietf-megaco-protocol-07.txt, > > > > > > is still ongoing work. AFAIK the protocol is still > > > > > > incomplete and > > > > > > largely unimplementable. A reference implementation > > > > > > has just been > > > > > > started. The working group is planning to > > > change the protocol > > > > > > semantics and transport syntax. There would be > > > no point in > > > > > > publishing the document as an RFC, if this were an > > > > > > IETF-only project > > > > > > > > > > > > As I have understood, publishing incomplete > > > recommendations is > > > > > > business as usual in ITU-T due to practical > > > reasons. The ITU-T > > > > > > recommendations must be approved using > > > time-consuming formal > > > > > > process, including a ballot. So, the finalized ITU-T > > > > > > specification > > > > > > actually consists of a recommendation document > > > > > > together with an > > > > > > Implementor's Guide correcting the errors and > > > omissions in the > > > > > > recommendation document. IG may contain major > > > changes that are > > > > > > incompatible with the published recommendation > > > > > > document. Also, when > > > > > > referring to a ITU-T specification, like > > > H.323v2, people are > > > > > > actually referring to the recommendation > > > together with the > > > > > > respective implementor's guide. > > > > > > > > > > > > The ITU-T process is (or at least should be) > > > familiar to the > > > > > > developers using ITU-T recommendations. > > > However, in Internet > > > > > > community people are expecting that the RFC is not > > > > > > just a snapshot > > > > > > of an on-going work. They don't anticipate that there > > > > > > is a companion > > > > > > document possibly changing the base protocol in > > > every turn. > > > > > > > > > > > > Proposal > > > > > > > > > > > > I propose that the MEGACO RFC should contain a > > > > > > paragraph explaining > > > > > > the status of the text, ie. that the protocol will be > > > > > > changed by an > > > > > > Implementors' Guide published soon. The MEGACO > > > RFC should also > > > > > > recommend that any reference to it must also be > > > > > > accompanied with a > > > > > > note explaining the status of the RFC, and a > > > reference to the > > > > > > Implementors' Guide. > > > > > > > > > > > > Best regards, > > > > > > Pekka Pesi > > > > > > > > > > > > > > Support NetAid! http://www.netaid.org > > > > -------------------------------------------------- > > > > Chip Sharp Consulting Engineering > > > > Cisco Systems Telco Bio-region > > > > Reality - Love it or Leave it. > > > > -------------------------------------------------- > > > ------_=_NextPart_001_01BF94D0.F8AFEF32 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Interop > Re: Proposal: explain MEGACO protocol RFC = status explicitly

I like the idea of a = test suite.  It would allow us to quickly verify the basic = mechanics in an agnostic way.  This would not test the specific = packages, which of course also need to be interoped, and would not be a = "test in practice".  Of course designing the suite would = take some time. 

I still believe that = deciding some simple, real, applications would be a VERY good step as = well, real soon.  Test suite would be an initial step only in my = mind.  Real applications is what we're trying to get to after all, = and we'll learn a lot more about the practical aspects through = these. 

My 0.02.  (How = much is that in Oz dollars, converted from Canadian?) 

-- Peter

    -----Original Message-----
    From:   Christian Groves = [SMTP:Christian.Groves@ERICSSON.COM]
    Sent:   23 Mar, 2000 01:01
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Re: Interop > Re: Proposal: = explain MEGACO protocol RFC status  explicitly

    G'Day Brian,

    Thanks for the update. Can you = elaborate on the "home" of this effort? I
    know you've done some work in MSF on = this. Can you provide some info to
    the list if you have more details of = what is to be tested and what the
    current plans are?

    Is it necessary to organise a = "home" for this effort? Sigtran it seems
    are doing a protocol interop test = without having to go to another forum.
    Interested parties are getting = together. Perhaps someone who
    participates in the Sigtran interop = can comment? Perhaps we could do
    something similar for Megaco?

    I'm glad that the first step with not = be part of a larger effort and
    will be done on simple devices. The = question is what sort of devices and
    what packages?

    I've envisaged that the test could be = done as you say between Megaco MGC
    and Megaco MG and would be agnostic = of the application and many
    packages. I saw that we test the root = package as it has protocol
    specific information and perhaps a = specifically developed test package
    that has a number of properties, = signals, events, statistics labelled in
    a very generic way. I didn't see that = we would do a simple IP phone or
    trunking GW interop. After all we = just need to test the Megaco
    mechanisms.

    A test profile containing test cases = and scripts could then be defined
    to test the various protocol = mechanism employed to relay the properties,
    signals, events and = statistics.

    We can worry about format and = reporting of the interop event when we get
    closer to it.

    Cheers, Christian

    "Rosen, Brian" wrote:
    >
    > I have been planning to (help) = organize early interoperability
    > testing.  There is some = experience in PacketCable and ISC
    > in testing MGCP that we can = leverage.
    >
    > I have been looking for a = "home" for this effort, and hope
    > to have that worked out = soon.
    >
    > I believe the first testing will = NOT be part of a larger testing
    > effort, and we will pair Megaco = MGCs with Megaco MGs for testing.
    > First tests will be done with = "simple" devices - no more than
    > a subset of the packages defined = in the original document.
    > We may have a test profile to = offer well in advance of the test
    > that will improve the = probability of many MGCs and MGs to try.
    > There will be some scripts = available.
    >
    > It will be open to all who have = devices to test.  It will be
    > "private" - no = observers, just engineer to engineer.  The only
    > reports issued will be summary = in nature and limited to areas
    > of confusion or other protocol = documentation issues.
    >
    > I'd like to hear from people = implementing the protocol when they
    > would be ready to start = testing.  I may have a "co-sponsor",
    > but others are welcome if they = are interested.
    >
    > Brian
    >
    > > -----Original = Message-----
    > > From: Christian Groves = [mailto:Christian.Groves@ER= ICSSON.COM]
    > > Sent: Tuesday, March 21, = 2000 10:27 PM
    > > To: = MEGACO@standards.nortelnetworks.com
    > > Subject: Interop > Re: = Proposal: explain MEGACO protocol RFC status
    > > explicitly
    > >
    > >
    > > G'Day all,
    > >
    > > Chip raises an interesting = issue of interoperability tests.
    > > The current
    > > plans for such testing = seems to me to be ambiguous at best.
    > >
    > > Due to the generic nature = of Megaco it seems to me to be
    > > quite difficult
    > > to test. From what I have = seen (please correct me if this isn't the
    > > case) is that Megaco/H248 = is planned to be tested as part of a larger
    > > application test. ie. = trunking gateway, IP phone etc. This to
    > > me seems a
    > > lot of overhead just to = test the megaco protocol. It also seems to put
    > > certain players of the = interop test. ie. if I make SIP GW which have
    > > h248 but the interop test = covers IP phones how do I get my
    > > Megaco stack
    > > tested???
    > >
    > > Are there any initiatives = where something similar to the following
    > > approach is taken? Do = people see merit in this?
    > > o The test is a test of the = protocol mechanisms.
    > > o Test between 2 boxes = (PCs, workstations etc) that implement
    > > H248 with
    > > the necessary SW to drive = the test. These boxes would be application
    > > agnostic.
    > > o A test package could be = developed with "dummy" properties, events,
    > > signals etc.
    > > o A test case document = which lists test cases for a good coverage test
    > > of Megaco. These test cases = could describe what should occur at dummy
    > > event detection.
    > >
    > > The aim of the approach is = an interop where people who intend to
    > > implement Megaco but not in = one of the proposed applications can test
    > > there stacks without having = to implement an entire application.
    > >
    > > If anyone has any = information of the current status of Megaco interops
    > > can they please share it on = the list.
    > >
    > > Cheers, Christian
    > >
    > >
    > > Chip Sharp wrote:
    > > >
    > > > As a further = clarification, independent of any judgement on
    > > megaco/H.248 in
    > > > particular, = publication of any RFC as Proposed Standard is really a
    > > > snapshot of the = development of the protocol.  At the point
    > > of publication
    > > > of the RFC as Proposed = Standard, the protocol is considered
    > > stable enough
    > > > to begin = implementation, perform interoperability tests and
    > > perhaps get
    > > > some deployment = experience (not necessarily in production networks).
    > > >
    > > > If during this = process, problems are found in the protocol
    > > and corrections
    > > > are needed, a new RFC = can be published with the corrections
    > > while still
    > > > remaining in Proposed = Standard state.
    > > >
    > > > There is no = requirement to implement an I-D before it moves
    > > to Proposed
    > > > Standard.  = Sometimes this is done and it definitely helps
    > > to get this
    > > > experience to learn = the ins and outs as the protocol is
    > > developed, but it
    > > > is not = required.
    > > >
    > > > As far as megaco/H.248 = is concerned, I do believe something like
    > > > implementer's = agreements (or profiles) will have to be
    > > worked out for
    > > > interoperability = reasons for specific applications since
    > > there are so many
    > > > options and different = ways of doing the same thing.
    > > Although there are
    > > > details we all don't = agree on, the IP Phone profile is one
    > > attempt at doing
    > > > this for an IP Phone = application.
    > > >
    > > > One thing to keep in = mind is that before megaco can move to
    > > Draft Standard
    > > > in IETF, all options = that don't have multiple interoperable
    > > implementations
    > > > have to be = removed.
    > > >
    > > > Chip
    > > >
    > > > At 08:50 AM 3/21/00 = -0500, Rosen, Brian wrote:
    > > > >I disagree with = your assessment of the state of the protocol.
    > > > >
    > > > >While there have = been a series of text change proposals made
    > > > >in the last few = weeks, all of them have either been requests
    > > > >to clear up = language, or proposals to fix some minor errors for
    > > > >unusual = circumstances.  In no case, AFAIK, would any of the changes
    > > > >invalidate any = existing implementation by more than a very minor
    > > > >addition.  = There are no plans for any major changes to syntax,
    > > > >and no changes at = all to semantics, unless you consider
    > > clarification
    > > > >of intent to be a = semantic change.  I don't understand the
    > > "transport
    > > > >syntax" part = at all, unless you are thinking about the ITU work
    > > > >on ATM transport = and SCTP annexes, which will not carry
    > > through to the
    > > > >IETF version on = present plans.
    > > > >
    > > > >There will be an = erratum published with the RFC.  Together, they
    > > > >should provide a = stable basis for the protocol.  The
    > > document is large.
    > > > >In any such = document, there are things that could use more
    > > explanation.
    > > > >While an = implementor's guide has been discussed, it has not yet
    > > > >been decided if we = will need one.  I suspect we will.  The
    > > guide will
    > > > >not, if I have = anything to do with it, change the protocol at all.
    > > > >If it needs to be = changed, we will have to have a new RFC.
    > > > >
    > > > >Brian
    > > > >
    > > > > > = -----Original Message-----
    > > > > > From: Pekka = Pessi [mailto:Pekka.Pessi@nokia.com]
    > > > > > Sent: = Tuesday, March 21, 2000 8:35 AM
    > > > > > To: = MEGACO@standards.nortelnetworks.com
    > > > > > Subject: = Proposal: explain MEGACO protocol RFC status explicitly
    > > > > >
    > > > > >
    > > > > = >         Hello all,
    > > > > >
    > > > > = >         The current = MEGACO/H.248 draft,
    > > > > > = draft-ietf-megaco-protocol-07.txt,
    > > > > = >         is still ongoing = work. AFAIK the protocol is still
    > > > > > incomplete = and
    > > > > = >         largely = unimplementable. A reference implementation
    > > > > > has just = been
    > > > > = >         started.  The = working group is planning to
    > > change the protocol
    > > > > = >         semantics and = transport syntax. There would be
    > > no point in
    > > > > = >         publishing the = document as an RFC, if this were an
    > > > > > IETF-only = project
    > > > > >
    > > > > = >         As I have = understood, publishing incomplete
    > > recommendations is
    > > > > = >         business as usual = in ITU-T due to practical
    > > reasons. The ITU-T
    > > > > = >         recommendations = must be approved using
    > > time-consuming = formal
    > > > > = >         process, including = a ballot. So, the finalized ITU-T
    > > > > > = specification
    > > > > = >         actually consists = of a recommendation document
    > > > > > together = with an
    > > > > = >         Implementor's = Guide correcting the errors and
    > > omissions in the
    > > > > = >         recommendation = document. IG may contain major
    > > changes that are
    > > > > = >         incompatible with = the published recommendation
    > > > > > = document.  Also, when
    > > > > = >         referring to a = ITU-T specification, like
    > > H.323v2, people are
    > > > > = >         actually referring = to the recommendation
    > > together with the
    > > > > = >         respective = implementor's guide.
    > > > > >
    > > > > = >         The ITU-T process = is (or at least should be)
    > > familiar to the
    > > > > = >         developers using = ITU-T recommendations.
    > > However, in Internet
    > > > > = >         community people = are expecting that the RFC is not
    > > > > > just a = snapshot
    > > > > = >         of an on-going = work. They don't anticipate that there
    > > > > > is a = companion
    > > > > = >         document possibly = changing the base protocol in
    > > every turn.
    > > > > >
    > > > > > = Proposal
    > > > > >
    > > > > = >         I propose that the = MEGACO RFC should contain a
    > > > > > paragraph = explaining
    > > > > = >         the status of the = text, ie. that the protocol will be
    > > > > > changed by = an
    > > > > = >         Implementors' = Guide published soon. The MEGACO
    > > RFC should also
    > > > > = >         recommend that any = reference to it must also be
    > > > > > accompanied = with a
    > > > > = >         note explaining = the status of the RFC, and a
    > > reference to the
    > > > > = >         Implementors' = Guide.
    > > > > >
    > > > > = >         Best = regards,
    > > > > = >           &n= bsp;           &n= bsp;           &n= bsp;     Pekka Pesi
    > > > > >
    > > >
    > > > Support = NetAid!  http://www.netaid.org
    > > > = --------------------------------------------------
    > > > Chip = Sharp           &= nbsp;     Consulting Engineering
    > > > Cisco = Systems           = ;   Telco Bio-region
    > > > Reality - Love it or = Leave it.
    > > > = --------------------------------------------------
    > >

------_=_NextPart_001_01BF94D0.F8AFEF32-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 23 12:57:33 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09387 for ; Thu, 23 Mar 2000 12:57:32 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.99CE41D0@standards.nortelnetworks.com>; Thu, 23 Mar 2000 12:52:09 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 100238 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 23 Mar 2000 12:50:29 -0500 Received: from smtprich.nortel.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5DDB45B0@standards.nortelnetworks.com>; Thu, 23 Mar 2000 12:50:28 -0500 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprich.nortel.com; Thu, 23 Mar 2000 11:55:37 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Mar 2000 11:54:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF94F0.DBD1C866" X-Orig: Message-ID: Date: Thu, 23 Mar 2000 11:54:37 -0600 Reply-To: Nancy-M Greene Sender: "Media Gateway Control (megaco)" From: Nancy-M Greene Subject: V16 Review - auditing unnamed digit maps 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_01BF94F0.DBD1C866 Content-Type: text/plain Here is an issue with auditing unnamed digit maps that has come up in our review of section 7.2.5 AuditValue: 7.2.5 AuditValue and the unnamed digit map Issue: in section 7.2.5 Audit Value, it mentions that DigitMapDescriptor can be audited and returns either the name or value. This should be more specific. A dumb MG may send name all the time while the MGC is interested in the value. We need to allow explicit request of name, value or both, especially to be sure to get something useful back when auditing for unnamed digit maps. Proposal: 1) we can give unnamed digit maps a name: "UNNAMED" . 2) Make the default meaning of the AuditValue command with respect to digit maps be to request reporting of names without values (and "unnamed" + value for every unnamed digit map). 3) to request reporting of names and values (unnamed use the name "UNNAMED") - introduce the token "A-" for "all" on the AuditValue command. Need something similar in the ASN.1 Comments? Nancy Abdallah -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com ------_=_NextPart_001_01BF94F0.DBD1C866 Content-Type: text/html Content-Transfer-Encoding: quoted-printable V16 Review - auditing unnamed digit maps

Here is an issue with auditing unnamed = digit maps that has come up in
our review of section 7.2.5 = AuditValue:=20

7.2.5 AuditValue and the unnamed digit = map
Issue: in section 7.2.5 Audit Value, = it mentions that DigitMapDescriptor
can be audited and returns either the = name or value. This should be
more specific. A dumb MG may send = name all the time while the MGC
is interested in the value. We need = to allow explicit request of name, value
or both, especially to be sure to get = something useful back when auditing
for unnamed digit maps.

Proposal: =
1) we can give unnamed digit maps a = name: "UNNAMED" .

2) Make the default meaning of the = AuditValue command with respect to
digit maps be to request reporting of = names without values (and "unnamed"
+ value for every unnamed digit = map).

3) to request reporting of names and = values (unnamed use the name
"UNNAMED") - introduce the = token "A-" for "all" on the AuditValue command. =
Need something similar in the = ASN.1
 
Comments?


Nancy
Abdallah


-----------------------------------------------------------------= ---------
Nancy M. Greene
Internet & Service = Provider Networks, Nortel Networks
T:514-271-7221 = (internal:ESN853-1077) E:ngreene@nortelnetworks.com

------_=_NextPart_001_01BF94F0.DBD1C866-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 23 12:57:34 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09389 for ; Thu, 23 Mar 2000 12:57:33 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9A2FE9D0@standards.nortelnetworks.com>; Thu, 23 Mar 2000 12:52:10 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 100243 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 23 Mar 2000 12:51:28 -0500 Received: from smtprtp.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.813CBCA0@standards.nortelnetworks.com>; Thu, 23 Mar 2000 12:51:28 -0500 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp.ntcom.nortel.net; Thu, 23 Mar 2000 12:55:05 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Mar 2000 12:55:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF94F0.E8874CCA" Message-ID: Date: Thu, 23 Mar 2000 12:54:53 -0500 Reply-To: Nancy-M Greene Sender: "Media Gateway Control (megaco)" From: Nancy-M Greene Subject: V16 review - Notify and error descriptor 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_01BF94F0.E8874CCA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Here is an issue with auditing unnamed digit maps that has come up in=20 our review of section 7.2.7 Notify and the related ABNF:=20 Section 7.2.7 Notify in ABNF Issue: NotifyRequest =3D NotifyToken EQUAL TerminationID=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 LBRKT observedEventsDescriptor=A0 [ = COMMA=20 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 errorDescriptor ] RBRKT=20 Comment: NotifyRequest used to read:=20 NotifyRequest =3D NotifyToken EQUAL TerminationID=20 =A0=A0=A0=A0=A0=A0=A0 LBRKT ( observedEventsDescriptor / = errorDescriptor ) RBRKT=20 It was changed because you can get more than one event per Notify, only = the last of which could have an error. A cleaner way to do this would = be to=20 reserve RequestID of 0 for asynchronous errors which occur = independently=20 of particular transactions or event requests and then move = errorDescriptor=20 to the observedEventsDescriptor. So it would look like this: NotifyRequest =3D NotifyToken EQUAL TerminationID=20 =A0=A0=A0 LBRKT observedEventsDescriptor RBRKT=20 observedEventsDescriptor =3D ...parameters=20 observedEventParameter =3D eventsStream/ eventOther / errorDescriptor=20 Any comments?=20 Nancy=20 Abdallah=20 ------------------------------------------------------------------------= -- Nancy M. Greene=20 Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com ------_=_NextPart_001_01BF94F0.E8874CCA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable V16 review - Notify and error descriptor

Here is an issue with auditing unnamed = digit maps that has come up in
our review of section 7.2.7 Notify = and the related ABNF:

Section 7.2.7 Notify in ABNF
Issue: NotifyRequest =3D NotifyToken = EQUAL TerminationID
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 LBRKT = observedEventsDescriptor=A0 [ COMMA
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = errorDescriptor ] RBRKT

Comment: NotifyRequest used to = read:
NotifyRequest =3D NotifyToken EQUAL = TerminationID
=A0=A0=A0=A0=A0=A0=A0 LBRKT ( = observedEventsDescriptor / errorDescriptor ) RBRKT

It was changed because you can get = more than one event per Notify, only
the last of which could have an = error. A cleaner way to do this would be to
reserve RequestID of 0 for = asynchronous errors which occur independently
of particular transactions or event = requests and then move errorDescriptor
to the observedEventsDescriptor. So = it would look like this:

NotifyRequest =3D NotifyToken EQUAL = TerminationID
=A0=A0=A0 LBRKT = observedEventsDescriptor RBRKT

observedEventsDescriptor =3D = ...parameters
observedEventParameter =3D = eventsStream/ eventOther / errorDescriptor =

Any comments?


Nancy
Abdallah
-----------------------------------------------------------------= ---------
Nancy M. Greene
Internet & Service = Provider Networks, Nortel Networks
T:514-271-7221 = (internal:ESN853-1077) E:ngreene@nortelnetworks.com

------_=_NextPart_001_01BF94F0.E8874CCA-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 23 13:18:08 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17118 for ; Thu, 23 Mar 2000 13:18:08 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.20735570@standards.nortelnetworks.com>; Thu, 23 Mar 2000 13:10:14 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 100278 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 23 Mar 2000 13:08:16 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.74AF46F0@standards.nortelnetworks.com>; Thu, 23 Mar 2000 12:58:16 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id NAA25480; Thu, 23 Mar 2000 13:02:46 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id NAA13696; Thu, 23 Mar 2000 13:02:48 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Mar 2000 12:58:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF94F1.5D0E3B8A" Message-ID: <4FBEA8857476D311A03300204840E1CF208B6F@whq-msgusr-02.fore.com> Date: Thu, 23 Mar 2000 13:02:04 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: V16 Review - auditing unnamed digit maps X-To: Nancy-M Greene 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_01BF94F1.5D0E3B8A Content-Type: text/plain; charset="iso-8859-1" I am in favor of auditValue always returning names and values, with the unnamed digitmap called "UNNAMED" I don't see great utility in an audit that just returns names. I don't like introducing "A-" This seems to be the simplest way to fix the real problem. Brian -----Original Message----- From: Nancy-M Greene [mailto:ngreene@nortelnetworks.com] Sent: Thursday, March 23, 2000 12:55 PM To: MEGACO@standards.nortelnetworks.com Subject: V16 Review - auditing unnamed digit maps Here is an issue with auditing unnamed digit maps that has come up in our review of section 7.2.5 AuditValue: 7.2.5 AuditValue and the unnamed digit map Issue: in section 7.2.5 Audit Value, it mentions that DigitMapDescriptor can be audited and returns either the name or value. This should be more specific. A dumb MG may send name all the time while the MGC is interested in the value. We need to allow explicit request of name, value or both, especially to be sure to get something useful back when auditing for unnamed digit maps. Proposal: 1) we can give unnamed digit maps a name: "UNNAMED" . 2) Make the default meaning of the AuditValue command with respect to digit maps be to request reporting of names without values (and "unnamed" + value for every unnamed digit map). 3) to request reporting of names and values (unnamed use the name "UNNAMED") - introduce the token "A-" for "all" on the AuditValue command. Need something similar in the ASN.1 Comments? Nancy Abdallah -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com ------_=_NextPart_001_01BF94F1.5D0E3B8A Content-Type: text/html; charset="iso-8859-1" V16 Review - auditing unnamed digit maps
I am in favor of auditValue always returning names and values, with
the unnamed digitmap called "UNNAMED"
 
I don't see great utility in an audit that just returns names.
 
I don't like introducing "A-"
 
This seems to be the simplest way to fix the real problem.
 
Brian
-----Original Message-----
From: Nancy-M Greene [mailto:ngreene@nortelnetworks.com]
Sent: Thursday, March 23, 2000 12:55 PM
To: MEGACO@standards.nortelnetworks.com
Subject: V16 Review - auditing unnamed digit maps

Here is an issue with auditing unnamed digit maps that has come up in
our review of section 7.2.5 AuditValue:

7.2.5 AuditValue and the unnamed digit map
Issue: in section 7.2.5 Audit Value, it mentions that DigitMapDescriptor
can be audited and returns either the name or value. This should be
more specific. A dumb MG may send name all the time while the MGC
is interested in the value. We need to allow explicit request of name, value
or both, especially to be sure to get something useful back when auditing
for unnamed digit maps.

Proposal:
1) we can give unnamed digit maps a name: "UNNAMED" .

2) Make the default meaning of the AuditValue command with respect to
digit maps be to request reporting of names without values (and "unnamed"
+ value for every unnamed digit map).

3) to request reporting of names and values (unnamed use the name
"UNNAMED") - introduce the token "A-" for "all" on the AuditValue command.
Need something similar in the ASN.1
 
Comments?


Nancy
Abdallah


--------------------------------------------------------------------------
Nancy M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

------_=_NextPart_001_01BF94F1.5D0E3B8A-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 23 13:42:13 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27277 for ; Thu, 23 Mar 2000 13:42:12 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C9821280@standards.nortelnetworks.com>; Thu, 23 Mar 2000 13:29:16 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 100321 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 23 Mar 2000 13:27:54 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.329121A0@standards.nortelnetworks.com>; Thu, 23 Mar 2000 13:17:54 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id NAA27765; Thu, 23 Mar 2000 13:22:29 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id NAA18355; Thu, 23 Mar 2000 13:22:32 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Mar 2000 13:18:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF94F4.1E1D0494" Message-ID: <4FBEA8857476D311A03300204840E1CF208B70@whq-msgusr-02.fore.com> Date: Thu, 23 Mar 2000 13:21:46 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: V16 review - Notify and error descriptor X-To: Nancy-M Greene 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_01BF94F4.1E1D0494 Content-Type: text/plain; charset="iso-8859-1" Although I see some value in the proposal, I think the current ABNF is okay, and propose to leave it as it is. Brian -----Original Message----- From: Nancy-M Greene [mailto:ngreene@nortelnetworks.com] Sent: Thursday, March 23, 2000 12:55 PM To: MEGACO@standards.nortelnetworks.com Subject: V16 review - Notify and error descriptor Here is an issue with auditing unnamed digit maps that has come up in our review of section 7.2.7 Notify and the related ABNF: Section 7.2.7 Notify in ABNF Issue: NotifyRequest = NotifyToken EQUAL TerminationID LBRKT observedEventsDescriptor [ COMMA errorDescriptor ] RBRKT Comment: NotifyRequest used to read: NotifyRequest = NotifyToken EQUAL TerminationID LBRKT ( observedEventsDescriptor / errorDescriptor ) RBRKT It was changed because you can get more than one event per Notify, only the last of which could have an error. A cleaner way to do this would be to reserve RequestID of 0 for asynchronous errors which occur independently of particular transactions or event requests and then move errorDescriptor to the observedEventsDescriptor. So it would look like this: NotifyRequest = NotifyToken EQUAL TerminationID LBRKT observedEventsDescriptor RBRKT observedEventsDescriptor = ...parameters observedEventParameter = eventsStream/ eventOther / errorDescriptor Any comments? Nancy Abdallah -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com ------_=_NextPart_001_01BF94F4.1E1D0494 Content-Type: text/html; charset="iso-8859-1" V16 review - Notify and error descriptor
Although I see some value in the proposal, I think the current
ABNF is okay, and propose to leave it as it is.
 
Brian
-----Original Message-----
From: Nancy-M Greene [mailto:ngreene@nortelnetworks.com]
Sent: Thursday, March 23, 2000 12:55 PM
To: MEGACO@standards.nortelnetworks.com
Subject: V16 review - Notify and error descriptor

Here is an issue with auditing unnamed digit maps that has come up in
our review of section 7.2.7 Notify and the related ABNF:

Section 7.2.7 Notify in ABNF
Issue: NotifyRequest = NotifyToken EQUAL TerminationID
           LBRKT observedEventsDescriptor  [ COMMA
           errorDescriptor ] RBRKT

Comment: NotifyRequest used to read:
NotifyRequest = NotifyToken EQUAL TerminationID
        LBRKT ( observedEventsDescriptor / errorDescriptor ) RBRKT

It was changed because you can get more than one event per Notify, only
the last of which could have an error. A cleaner way to do this would be to
reserve RequestID of 0 for asynchronous errors which occur independently
of particular transactions or event requests and then move errorDescriptor
to the observedEventsDescriptor. So it would look like this:

NotifyRequest = NotifyToken EQUAL TerminationID
    LBRKT observedEventsDescriptor RBRKT

observedEventsDescriptor = ...parameters
observedEventParameter = eventsStream/ eventOther / errorDescriptor

Any comments?


Nancy
Abdallah
--------------------------------------------------------------------------
Nancy M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

------_=_NextPart_001_01BF94F4.1E1D0494-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 23 14:00:19 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04381 for ; Thu, 23 Mar 2000 14:00:18 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.034D6C50@standards.nortelnetworks.com>; Thu, 23 Mar 2000 13:52:22 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 100389 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 23 Mar 2000 13:51:04 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D4D20250@standards.nortelnetworks.com>; Thu, 23 Mar 2000 13:51:04 -0500 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Thu, 23 Mar 2000 11:55:09 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Mar 2000 11:54:21 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF94F0.D16AA5B4" Message-ID: Date: Thu, 23 Mar 2000 11:54:20 -0600 Reply-To: Nancy-M Greene Sender: "Media Gateway Control (megaco)" From: Nancy-M Greene Subject: V16 Review - Auditing contexts and their terminations 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_01BF94F0.D16AA5B4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Here are 2 issues with the ABNF that have come up on our review of=20 section 7.2.5 AuditValue:=20 1) 7.2.5 Audit Value - auditing all matching terminations and their=20 contexts =20 Issue: The entry before the last in table we have=20 "ContextID=3DALL=A0 , TerminationID=3D wildcard, Audit of all matching=20 terminations and contexts to which they are associated."=20 Comment: In the ABNF, the reply reads like this:=20 AuditValue =3D contextID { t1,t2,...}=20 We can't report all the contexts in this reply. The ABNF must be fixed to allow returning list of contexts=20 rather than just one with a list of terminations.=20 2) 7.2.5 Audit Value - return all context ids=20 Issue: The last entry in the table is: ContextID=3DAll, TerminationID=3DRoot, list of all contextIDs,=20 Comment: The ABNF does not allow a list of contextIDs=20 returned on the audit. This has to be fixed to allow list of=20 contexts.=20 Also, we need to check whether the ASN.1 handles these 2 cases=20 correctly. Proposal: A proposal for solving these 2 issues in the ABNF:=20 Auditing a context does not belong to any particular command. So it=20 should stay out of AuditRequest. We already have a contextAudit in the=20 ABNF, so we should use it instead.=20 Case 1: List of all contexts and all terminations:=20 Request: Context =3D ALL {ContextAudit{Terminations}, othercommands = ....}=20 Reply: Context=3DAll {Root { Cid1 { t1,t2,3....}, Cid2 { ....}}, other replies}=20 ; Terminations will be a new token added to contextAuditProperties=20 ; and we will need RootDescriptor (list of lists as above)=20 Case 2: All terminations and a specific context=20 Request: Context=3DCid {ContextAudit{Terminations}, othercommands ...}=20 Reply: Context=3DCid { Terminations { t1,2,t3, ...}, other replies}=20 ; same as above but with TerminationsDescriptor this time (list of=20 ; terminations=20 Case 3: All contexts, no terminations=20 Request: Context=3DCid or ALL {ContextAudit{Root}, othercommands ...}=20 Reply: Context=3DCid or ALL { Contexts { cid1,cid2,cid3, ...}, other = replies}=20 ; RootToken, ContextsToken and ContextsDescriptor.=20 This way we avoid falling into explaining AuditValue or AuditCapability = for context audit and at the same time, auditing context at the context = level. Also, remove contextTerminationsAudit from auditReply.=20 Comments?=20 Nancy Abdallah ------------------------------------------------------------------------= -- Nancy M. Greene=20 Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com ------_=_NextPart_001_01BF94F0.D16AA5B4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable V16 Review - Auditing contexts and their terminations

Here are 2 issues with the ABNF that = have come up on our review of
section 7.2.5 AuditValue:

1) 7.2.5 Audit Value - auditing all = matching terminations and their
contexts
 
Issue: The entry before the last in = table we have
"ContextID=3DALL=A0 , = TerminationID=3D wildcard, Audit of all matching
terminations and contexts to which = they are associated."

Comment: In the ABNF, the reply reads = like this:
AuditValue =3D contextID { = t1,t2,...}
We can't report all the contexts in = this reply.
The ABNF must be fixed to allow = returning list of contexts
rather than just one with a list of = terminations.

2) 7.2.5 Audit Value - return all = context ids

Issue: The last entry in the table = is:
ContextID=3DAll, = TerminationID=3DRoot, list of all contextIDs,

Comment: The ABNF does not allow a = list of contextIDs
returned on the audit. This has to be = fixed to allow list of
contexts. =

Also, we need to check whether the = ASN.1 handles these 2 cases
correctly.

Proposal: A proposal for = solving these 2 issues in the ABNF:

Auditing a context does not belong to = any particular command. So it
should stay out of AuditRequest. We = already have a contextAudit in the
ABNF, so we should use it instead. =

Case 1: List of all contexts and all = terminations:
Request: Context =3D ALL = {ContextAudit{Terminations}, othercommands ....}
Reply: Context=3DAll {Root { Cid1 { = t1,t2,3....}, Cid2 { ....}}, other replies} =
; Terminations will be a new token = added to contextAuditProperties
; and we will need RootDescriptor = (list of lists as above)

Case 2: All terminations and a = specific context
Request: Context=3DCid = {ContextAudit{Terminations}, othercommands ...}
Reply: Context=3DCid { Terminations { = t1,2,t3, ...}, other replies}
; same as above but with = TerminationsDescriptor this time (list of =
; terminations

Case 3: All contexts, no = terminations
Request: Context=3DCid or ALL = {ContextAudit{Root}, othercommands ...} =
Reply: Context=3DCid or ALL { = Contexts { cid1,cid2,cid3, ...}, other replies}
; RootToken, ContextsToken and = ContextsDescriptor.

This way we avoid falling into = explaining AuditValue or AuditCapability =
for context audit and at the same = time, auditing context at the context =
level. Also, remove = contextTerminationsAudit from auditReply. =

Comments? =

Nancy
Abdallah

-----------------------------------------------------------------= ---------
Nancy M. Greene
Internet & Service = Provider Networks, Nortel Networks
T:514-271-7221 = (internal:ESN853-1077) E:ngreene@nortelnetworks.com

------_=_NextPart_001_01BF94F0.D16AA5B4-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 23 16:51:51 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03430 for ; Thu, 23 Mar 2000 16:51:51 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.629150B0@standards.nortelnetworks.com>; Thu, 23 Mar 2000 16:46:50 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 100742 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 23 Mar 2000 16:45:36 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.369E6650@standards.nortelnetworks.com>; Thu, 23 Mar 2000 16:45:36 -0500 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Thu, 23 Mar 2000 14:29:44 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 23 Mar 2000 14:29:20 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF9506.76782170" Message-ID: Date: Thu, 23 Mar 2000 14:29:15 -0600 Reply-To: Nancy-M Greene Sender: "Media Gateway Control (megaco)" From: Nancy-M Greene Subject: V16 review - events Descriptor 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_01BF9506.76782170 Content-Type: text/plain This comment is editorial, trying to improve the clarity of section 7.1.9: (and, it is, I hope, our last comment on v16 :-) ) Section 7.1.9 Events Descriptor Issue: Case 1, item 2a), and Case 2 are not yet completely clear. Case 1, item 2a) currently says: "... detected. The MG then waits for a new EventsDescriptor. While waiting for a new EventsDescriptor, any events matching the EventsBufferDescriptor will be placed in the EventBuffer and the event processing will repeat from step 1." Proposal: i) Change "While waiting..." sentence in Case 1, item 2a) to be: "While waiting for a new EventsDescriptor, any events detected which appear in the current EventsBufferDescriptor will be placed in the EventBuffer. When a new EventDescriptor is received, event processing repeats from step 1." ii) and add this sentence to Case 2: "Events detected that match an event in the new EventsDescriptor are immediately notified." Nancy Abdallah -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com ------_=_NextPart_001_01BF9506.76782170 Content-Type: text/html Content-Transfer-Encoding: quoted-printable V16 review - events Descriptor

This comment is editorial, trying to = improve the clarity of section 7.1.9:

(and, it is, I hope, our last comment = on v16 :-) )

Section 7.1.9 Events = Descriptor
Issue: Case 1, item 2a), and Case 2 = are not yet completely clear.
Case 1, item 2a) currently says: =
"... detected. The MG then waits = for a new EventsDescriptor. While waiting
for a new EventsDescriptor, = any events matching the EventsBufferDescriptor
will be placed in the = EventBuffer and the event processing will repeat from
step 1."

Proposal: =
i) Change "While = waiting..." sentence in Case 1, item 2a) to be:
"While waiting for a new = EventsDescriptor, any events detected which =
appear in the current = EventsBufferDescriptor will be placed in the EventBuffer.
When a new EventDescriptor is = received, event processing repeats
from step 1."

ii) and add this sentence to Case = 2:
"Events detected that match an = event in the new EventsDescriptor are
immediately = notified."

Nancy
Abdallah


-----------------------------------------------------------------= ---------
Nancy M. Greene
Internet & Service = Provider Networks, Nortel Networks
T:514-271-7221 = (internal:ESN853-1077) E:ngreene@nortelnetworks.com

------_=_NextPart_001_01BF9506.76782170-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 23 17:19:16 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13513 for ; Thu, 23 Mar 2000 17:19:16 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.069DE620@standards.nortelnetworks.com>; Thu, 23 Mar 2000 17:12:53 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 100776 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 23 Mar 2000 17:11:30 -0500 Received: from sourcenet.org (209.214.98.210) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6E6D7060@standards.nortelnetworks.com>; Thu, 23 Mar 2000 17:01:29 -0500 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <702.10740.824052@sourcenet.org> Date: Thu, 23 Mar 2000 17:11:30 -0500 Reply-To: jeffallen@SOURCENET.ORG Sender: "Media Gateway Control (megaco)" From: jeffallen@SOURCENET.ORG Subject: Information you requested about savings on your current utilities To: MEGACO@STANDARDS.NORTELNETWORKS.COM You requested information on how you could save 30% on your phone bill and receive up to 8% back each month on your utilities. http://www.acninc.com RUID# 0392753 ACN is a cooperative marketing company capitalizing on the world-wide deregulation of the utilities industries (Telecommunications / Internet / Gas and Electricity). ACN's services are attractively priced: FREE* paging service, FREE* unlimited Internet service, Long Distance as low as 5-cents a minute with ONE second billing (no rounding to the nearest minute) with a FREE 800 number! Try the long distance service 5 cents per minute 24/7 and pay no switching fees and if you decide after a month or two that you want to go back we'll switch you back for free. With the free 800#, give it out to your kids and other family members. When they call you it won't cost them anything and will only cost you 10 cents per minute. The company I am with is saving 50% on their long distance because our rates are half of what they were with the other carrier. This long distance works well with both businesses as well as residences. Our company signed up as a rep so that we could offer this as a service to all our customers and suppliers, and we get up to 8% each and every month based on the amount of their usage. I used to use AT&T for all my long distance and cellular services. They first called me up because I was using another company and making a lot of international calls. They said they were competitive with my current carrier with better customer service. Well, they switched over my long distance but for to put me onto their international plan. I got a good discount for calls within the United States but my International rates went up over 1000%. Their customer service refused to give me any credit whatsoever and I decided to look around for other options. That's how I found the CAN. I now earn up to 8% on everybody I refer to this service. Whether you sign up as a customer or representative, you can't lose. Worse case scenario, you'll only save money. I will follow up again later and let you know more about the business opportunity of sharing this with people you know. Jeffrey Solochek 912-826-1311 . From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 23 19:59:31 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08496 for ; Thu, 23 Mar 2000 19:59:30 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.979789E0@standards.nortelnetworks.com>; Thu, 23 Mar 2000 19:54:26 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 101171 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 23 Mar 2000 19:53:52 -0500 Received: from ish7.ericsson.com.au (203.61.155.111) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1D774E80@standards.nortelnetworks.com>; Thu, 23 Mar 2000 19:43:51 -0500 Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id LAA03743; Fri, 24 Mar 2000 11:47:13 +1100 (EST) Received: from mcsi00.epa.ericsson.se (mcsi00 [146.11.8.201]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id LAA28992; Fri, 24 Mar 2000 11:47:53 +1100 (EST) Received: from ericsson.com (mc2dh6.epa.ericsson.se [146.11.87.6]) by mcsi00.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA00398; Fri, 24 Mar 2000 11:47:04 +1100 (EST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <29400B68197CD31188830000F8CD15D343BCE7@zcard00q.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38DABB11.E8F5DB43@ericsson.com> Date: Fri, 24 Mar 2000 11:47:13 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Interop > Re: Proposal: explain MEGACO protocol RFC status explicitly X-To: Peter Blatherwick To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Pete, I am proposing that a test suite is a first step towards more of a full interop test. I think that to satisfy IETF requirements what we need is a simple protocol test. Applications such as Tiphon, IP phones, MSF, BICC etc are best interop tested as a whole in the relevant organisations. These depend on several elements working ie. RTP stack, codecs, etc. Real applications are of course the aim at the end of the day but we need to start somewhere. My 5c worth (we don't 1 or 2 cent coins in OZ) Cheers, Christian Peter Blatherwick wrote: > > I like the idea of a test suite. It would allow us to quickly verify > the basic mechanics in an agnostic way. This would not test the > specific packages, which of course also need to be interoped, and > would not be a "test in practice". Of course designing the suite > would take some time. > > I still believe that deciding some simple, real, applications would be > a VERY good step as well, real soon. Test suite would be an initial > step only in my mind. Real applications is what we're trying to get > to after all, and we'll learn a lot more about the practical aspects > through these. > > My 0.02. (How much is that in Oz dollars, converted from Canadian?) > > -- Peter > > -----Original Message----- > From: Christian Groves [SMTP:Christian.Groves@ERICSSON.COM] > Sent: 23 Mar, 2000 01:01 > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Interop > Re: Proposal: explain MEGACO > protocol RFC status explicitly > > G'Day Brian, > > Thanks for the update. Can you elaborate on the "home" of this > effort? I > know you've done some work in MSF on this. Can you provide some > info to > the list if you have more details of what is to be tested and > what the > current plans are? > > Is it necessary to organise a "home" for this effort? Sigtran it > seems > are doing a protocol interop test without having to go to another > forum. > Interested parties are getting together. Perhaps someone who > participates in the Sigtran interop can comment? Perhaps we could > do > something similar for Megaco? > > I'm glad that the first step with not be part of a larger effort > and > will be done on simple devices. The question is what sort of > devices and > what packages? > > I've envisaged that the test could be done as you say between > Megaco MGC > and Megaco MG and would be agnostic of the application and many > packages. I saw that we test the root package as it has protocol > specific information and perhaps a specifically developed test > package > that has a number of properties, signals, events, statistics > labelled in > a very generic way. I didn't see that we would do a simple IP > phone or > trunking GW interop. After all we just need to test the Megaco > mechanisms. > > A test profile containing test cases and scripts could then be > defined > to test the various protocol mechanism employed to relay the > properties, > signals, events and statistics. > > We can worry about format and reporting of the interop event when > we get > closer to it. > > Cheers, Christian > > "Rosen, Brian" wrote: > > > > I have been planning to (help) organize early interoperability > > testing. There is some experience in PacketCable and ISC > > in testing MGCP that we can leverage. > > > > I have been looking for a "home" for this effort, and hope > > to have that worked out soon. > > > > I believe the first testing will NOT be part of a larger > testing > > effort, and we will pair Megaco MGCs with Megaco MGs for > testing. > > First tests will be done with "simple" devices - no more than > > a subset of the packages defined in the original document. > > We may have a test profile to offer well in advance of the test > > > that will improve the probability of many MGCs and MGs to try. > > There will be some scripts available. > > > > It will be open to all who have devices to test. It will be > > "private" - no observers, just engineer to engineer. The only > > reports issued will be summary in nature and limited to areas > > of confusion or other protocol documentation issues. > > > > I'd like to hear from people implementing the protocol when > they > > would be ready to start testing. I may have a "co-sponsor", > > but others are welcome if they are interested. > > > > Brian > > > > > -----Original Message----- > > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > > > > Sent: Tuesday, March 21, 2000 10:27 PM > > > To: MEGACO@standards.nortelnetworks.com > > > Subject: Interop > Re: Proposal: explain MEGACO protocol RFC > status > > > explicitly > > > > > > > > > G'Day all, > > > > > > Chip raises an interesting issue of interoperability tests. > > > The current > > > plans for such testing seems to me to be ambiguous at best. > > > > > > Due to the generic nature of Megaco it seems to me to be > > > quite difficult > > > to test. From what I have seen (please correct me if this > isn't the > > > case) is that Megaco/H248 is planned to be tested as part of > a larger > > > application test. ie. trunking gateway, IP phone etc. This to > > > > me seems a > > > lot of overhead just to test the megaco protocol. It also > seems to put > > > certain players of the interop test. ie. if I make SIP GW > which have > > > h248 but the interop test covers IP phones how do I get my > > > Megaco stack > > > tested??? > > > > > > Are there any initiatives where something similar to the > following > > > approach is taken? Do people see merit in this? > > > o The test is a test of the protocol mechanisms. > > > o Test between 2 boxes (PCs, workstations etc) that implement > > > > H248 with > > > the necessary SW to drive the test. These boxes would be > application > > > agnostic. > > > o A test package could be developed with "dummy" properties, > events, > > > signals etc. > > > o A test case document which lists test cases for a good > coverage test > > > of Megaco. These test cases could describe what should occur > at dummy > > > event detection. > > > > > > The aim of the approach is an interop where people who intend > to > > > implement Megaco but not in one of the proposed applications > can test > > > there stacks without having to implement an entire > application. > > > > > > If anyone has any information of the current status of Megaco > interops > > > can they please share it on the list. > > > > > > Cheers, Christian > > > > > > > > > Chip Sharp wrote: > > > > > > > > As a further clarification, independent of any judgement on > > > > megaco/H.248 in > > > > particular, publication of any RFC as Proposed Standard is > really a > > > > snapshot of the development of the protocol. At the point > > > of publication > > > > of the RFC as Proposed Standard, the protocol is considered > > > > stable enough > > > > to begin implementation, perform interoperability tests and > > > > perhaps get > > > > some deployment experience (not necessarily in production > networks). > > > > > > > > If during this process, problems are found in the protocol > > > and corrections > > > > are needed, a new RFC can be published with the corrections > > > > while still > > > > remaining in Proposed Standard state. > > > > > > > > There is no requirement to implement an I-D before it moves > > > > to Proposed > > > > Standard. Sometimes this is done and it definitely helps > > > to get this > > > > experience to learn the ins and outs as the protocol is > > > developed, but it > > > > is not required. > > > > > > > > As far as megaco/H.248 is concerned, I do believe something > like > > > > implementer's agreements (or profiles) will have to be > > > worked out for > > > > interoperability reasons for specific applications since > > > there are so many > > > > options and different ways of doing the same thing. > > > Although there are > > > > details we all don't agree on, the IP Phone profile is one > > > attempt at doing > > > > this for an IP Phone application. > > > > > > > > One thing to keep in mind is that before megaco can move to > > > > Draft Standard > > > > in IETF, all options that don't have multiple interoperable > > > > implementations > > > > have to be removed. > > > > > > > > Chip > > > > > > > > At 08:50 AM 3/21/00 -0500, Rosen, Brian wrote: > > > > >I disagree with your assessment of the state of the > protocol. > > > > > > > > > >While there have been a series of text change proposals > made > > > > >in the last few weeks, all of them have either been > requests > > > > >to clear up language, or proposals to fix some minor > errors for > > > > >unusual circumstances. In no case, AFAIK, would any of > the changes > > > > >invalidate any existing implementation by more than a very > minor > > > > >addition. There are no plans for any major changes to > syntax, > > > > >and no changes at all to semantics, unless you consider > > > clarification > > > > >of intent to be a semantic change. I don't understand the > > > > "transport > > > > >syntax" part at all, unless you are thinking about the ITU > work > > > > >on ATM transport and SCTP annexes, which will not carry > > > through to the > > > > >IETF version on present plans. > > > > > > > > > >There will be an erratum published with the RFC. > Together, they > > > > >should provide a stable basis for the protocol. The > > > document is large. > > > > >In any such document, there are things that could use more > > > > explanation. > > > > >While an implementor's guide has been discussed, it has > not yet > > > > >been decided if we will need one. I suspect we will. The > > > > guide will > > > > >not, if I have anything to do with it, change the protocol > at all. > > > > >If it needs to be changed, we will have to have a new RFC. > > > > > > > > > > >Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > > > > > Sent: Tuesday, March 21, 2000 8:35 AM > > > > > > To: MEGACO@standards.nortelnetworks.com > > > > > > Subject: Proposal: explain MEGACO protocol RFC status > explicitly > > > > > > > > > > > > > > > > > > Hello all, > > > > > > > > > > > > The current MEGACO/H.248 draft, > > > > > > draft-ietf-megaco-protocol-07.txt, > > > > > > is still ongoing work. AFAIK the protocol is > still > > > > > > incomplete and > > > > > > largely unimplementable. A reference > implementation > > > > > > has just been > > > > > > started. The working group is planning to > > > change the protocol > > > > > > semantics and transport syntax. There would be > > > no point in > > > > > > publishing the document as an RFC, if this were > an > > > > > > IETF-only project > > > > > > > > > > > > As I have understood, publishing incomplete > > > recommendations is > > > > > > business as usual in ITU-T due to practical > > > reasons. The ITU-T > > > > > > recommendations must be approved using > > > time-consuming formal > > > > > > process, including a ballot. So, the finalized > ITU-T > > > > > > specification > > > > > > actually consists of a recommendation document > > > > > > together with an > > > > > > Implementor's Guide correcting the errors and > > > omissions in the > > > > > > recommendation document. IG may contain major > > > changes that are > > > > > > incompatible with the published recommendation > > > > > > document. Also, when > > > > > > referring to a ITU-T specification, like > > > H.323v2, people are > > > > > > actually referring to the recommendation > > > together with the > > > > > > respective implementor's guide. > > > > > > > > > > > > The ITU-T process is (or at least should be) > > > familiar to the > > > > > > developers using ITU-T recommendations. > > > However, in Internet > > > > > > community people are expecting that the RFC is > not > > > > > > just a snapshot > > > > > > of an on-going work. They don't anticipate that > there > > > > > > is a companion > > > > > > document possibly changing the base protocol in > > > > every turn. > > > > > > > > > > > > Proposal > > > > > > > > > > > > I propose that the MEGACO RFC should contain a > > > > > > paragraph explaining > > > > > > the status of the text, ie. that the protocol > will be > > > > > > changed by an > > > > > > Implementors' Guide published soon. The MEGACO > > > RFC should also > > > > > > recommend that any reference to it must also be > > > > > > > accompanied with a > > > > > > note explaining the status of the RFC, and a > > > reference to the > > > > > > Implementors' Guide. > > > > > > > > > > > > Best regards, > > > > > > Pekka Pesi > > > > > > > > > > > > > > Support NetAid! http://www.netaid.org > > > > -------------------------------------------------- > > > > Chip Sharp Consulting Engineering > > > > Cisco Systems Telco Bio-region > > > > Reality - Love it or Leave it. > > > > -------------------------------------------------- > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 24 04:22:15 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19369 for ; Fri, 24 Mar 2000 04:22:14 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C85CBA00@standards.nortelnetworks.com>; Fri, 24 Mar 2000 4:16:52 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 101510 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 24 Mar 2000 04:15:42 -0500 Received: from mgw-x2.nokia.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9E6CCB90@standards.nortelnetworks.com>; Fri, 24 Mar 2000 4:15:42 -0500 Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id LAA22145 for ; Fri, 24 Mar 2000 11:20:20 +0200 (EET) Received: from loki.research.nokia.com (loki.research.nokia.com [172.21.33.76]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id LAA24973 for ; Fri, 24 Mar 2000 11:20:20 +0200 (EET) Received: from rama.research.nokia.com (IDENT:root@rama.research.nokia.com [172.21.40.44]) by loki.research.nokia.com (8.9.3/8.9.3) with ESMTP id LAA09633 for ; Fri, 24 Mar 2000 11:20:19 +0200 (EET) Received: (from ppessi@localhost) by rama.research.nokia.com (8.9.3/8.9.1) id LAA29834; Fri, 24 Mar 2000 11:20:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Message-ID: <14555.13138.796693.638886@rama.research.nokia.com> Date: Fri, 24 Mar 2000 11:20:18 +0200 Reply-To: Pekka.Pessi@nokia.com Sender: "Media Gateway Control (megaco)" From: Pekka Pessi Subject: Conversion errors in draft-ietf-megaco-protocol-07.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello, The current I-D draft-ietf-megaco-protocol-07.txt is missing some text found in the word/PDF files. Some special characters, like backslash "\", seem to be confusing the software converting the word file. The lossage is worst in the appendix specifying the ABNF, i.e. the IETF-specific part of the spec. Unless the conversion errors are fixed, the errors make draft-ietf-megaco-protocol-07.txt (and the Proposed Standard based on it) quite useless as a basis for implementation. I mean, one has to check every detail with the PDF/Word files. So, I wonder, that is the point here publishing draft-ietf-megaco-protocol-07.txt? Regards, Pekka Pessi From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 24 06:42:28 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07300 for ; Fri, 24 Mar 2000 06:42:28 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5CF20270@standards.nortelnetworks.com>; Fri, 24 Mar 2000 6:37:02 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 101623 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 24 Mar 2000 06:35:57 -0500 Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CECE0760@standards.nortelnetworks.com>; Fri, 24 Mar 2000 6:25:54 -0500 Received: from hgupta ([172.25.1.130]) by ficon-tech.com (8.9.3/8.8.7) with SMTP id QAA39799 for ; Fri, 24 Mar 2000 16:55:37 +0530 (IST) (envelope-from hkumar@ficon-tech.com) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005B_01BF95B2.84C3B940" 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: <005e01bf9584$6f4cf780$820119ac@india.ficontech.com> Date: Fri, 24 Mar 2000 17:00:54 +0530 Reply-To: Hemant Sender: "Media Gateway Control (megaco)" From: Hemant Subject: Re: Descriptor processing order To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_005B_01BF95B2.84C3B940 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I wish to have some clarification on the issue of command being = atomic. Does this imply that if an activity has been initiated by the MG in = response to a command and subsequently a failure occurs during its = processing, the MG should rollback all actions that have happened till = that point in the command (in which error has occurred). For e.g. - The MG is looking for some Events on a particular termination - A modify command containing another event desc. and signal desc. is = received for that termination (Descriptors in that order) - The events are configured in the MG ( acc. to the new event desc.) - Error is encountered in the MG while allocation of the resources for = generating signals - Rollback implies that the MG stop looking the current event and again = start looking for the initial events. If rollback is what the protocol implies than there will be more = complications if embedded commands were to be treated as atomic. Regards, Hemant ------------------------------------------------ Hemant Kumar Ficon Technology E-mail: mailto:hkumar@ficon-tech.com Web: http://www.ficon-tech.com ------------------------------------------------ ------=_NextPart_000_005B_01BF95B2.84C3B940 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
     I wish to = have some=20 clarification on the issue of command being atomic.
Does this imply that if an = activity has been=20 initiated by the MG in response to a command and subsequently a = failure=20 occurs during its processing, the MG should rollback all actions = that have=20 happened till that point in the command (in which error has=20 occurred).
 
For e.g.
- The MG is looking for some = Events on a=20 particular termination
- A modify command containing = another event=20 desc. and signal desc. is received for that termination (Descriptors in = that=20 order)
- The events are configured in the MG ( = acc. to the=20 new event desc.)
- Error is encountered in the MG while = allocation=20 of the resources for generating signals
- Rollback implies that the MG stop = looking the=20 current event and again start looking for the initial = events.
 
If rollback is what the protocol = implies than there=20 will be more complications if embedded commands were to be treated = as=20 atomic.
 
Regards,
Hemant

------------------------------------------------
Hemant=20 Kumar
Ficon Technology
E-mail: mailto:hkumar@ficon-tech.comWeb: http://www.ficon-tech.com
------------------------------------------------
------=_NextPart_000_005B_01BF95B2.84C3B940-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 24 07:55:29 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01751 for ; Fri, 24 Mar 2000 07:55:28 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.925B8490@standards.nortelnetworks.com>; Fri, 24 Mar 2000 7:50:06 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 101673 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 24 Mar 2000 07:48:41 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F9710DA0@standards.nortelnetworks.com>; Fri, 24 Mar 2000 7:38:40 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id HAA29448; Fri, 24 Mar 2000 07:43:18 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id HAA14299; Fri, 24 Mar 2000 07:43:21 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Fri, 24 Mar 2000 07:38:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF208B80@whq-msgusr-02.fore.com> Date: Fri, 24 Mar 2000 07:42:37 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Conversion errors in draft-ietf-megaco-protocol-07.txt X-To: "Pekka.Pessi@nokia.com" To: MEGACO@STANDARDS.NORTELNETWORKS.COM We must publish .txt files for the IETF process. I've been using the same tools since the first draft was published, and no one has pointed out any errors other than some table formatting, and a few missed directives. I will look into the problem, and have it fixed for the RFC. I'd suggest you use the .doc or .pdf files in most cases, as they are more readable, but I have spent many hours making the .txt files for those who want them, and aim to have them be as accurate as possible. The last draft was rushed, so it's possible that I did something wrong there. At any rate, I apologize, and will have this particular problem cleaned up for whatever comes next. If you spot anything else, please let me know. Brian > -----Original Message----- > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > Sent: Friday, March 24, 2000 4:20 AM > To: MEGACO@standards.nortelnetworks.com > Subject: Conversion errors in draft-ietf-megaco-protocol-07.txt > > > Hello, > > The current I-D draft-ietf-megaco-protocol-07.txt is > missing some > text found in the word/PDF files. Some special > characters, like > backslash "\", seem to be confusing the software > converting the word > file. The lossage is worst in the appendix specifying > the ABNF, i.e. > the IETF-specific part of the spec. > > Unless the conversion errors are fixed, the errors make > draft-ietf-megaco-protocol-07.txt (and the Proposed > Standard based > on it) quite useless as a basis for implementation. I > mean, one has > to check every detail with the PDF/Word files. > > So, I wonder, that is the point here publishing > draft-ietf-megaco-protocol-07.txt? > > Regards, > Pekka Pessi > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 24 08:09:21 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07287 for ; Fri, 24 Mar 2000 08:09:20 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.883F4080@standards.nortelnetworks.com>; Fri, 24 Mar 2000 8:04:08 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 101691 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 24 Mar 2000 08:02:46 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F1747540@standards.nortelnetworks.com>; Fri, 24 Mar 2000 7:52:46 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id HAA00299; Fri, 24 Mar 2000 07:57:23 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id HAA15778; Fri, 24 Mar 2000 07:57:26 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Fri, 24 Mar 2000 07:52:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF958F.DCACE5E6" Message-ID: <4FBEA8857476D311A03300204840E1CF208B81@whq-msgusr-02.fore.com> Date: Fri, 24 Mar 2000 07:56:40 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Descriptor processing order X-To: Hemant 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_01BF958F.DCACE5E6 Content-Type: text/plain; charset="iso-8859-1" Hemant Yes, it implies rollback, although I wouldn't implement it that way (I'd allocate all the resources, then make the state changes). At some point, you have a balance between discriminating errors and ease of implementation, as well as one between the complexity of the syntax and ease of implementation. If we were to say that the descriptors are executed in order, and errors can occur at any descriptor, then what about your example where the signals descriptor contains two signals, the first is okay, but the second fails? Should we remove the first? That's atomicity of descriptors. Should we allow sequential execution of elements in a descriptor or force "rollback" within the descriptor? Please do keep in mind that I advocated atomicity of transactions, and was in a distinct minority. Brian -----Original Message----- From: Hemant [mailto:hkumar@ficon-tech.com] Sent: Friday, March 24, 2000 6:31 AM To: MEGACO@standards.nortelnetworks.com Subject: Re: Descriptor processing order Hi, I wish to have some clarification on the issue of command being atomic. Does this imply that if an activity has been initiated by the MG in response to a command and subsequently a failure occurs during its processing, the MG should rollback all actions that have happened till that point in the command (in which error has occurred). For e.g. - The MG is looking for some Events on a particular termination - A modify command containing another event desc. and signal desc. is received for that termination (Descriptors in that order) - The events are configured in the MG ( acc. to the new event desc.) - Error is encountered in the MG while allocation of the resources for generating signals - Rollback implies that the MG stop looking the current event and again start looking for the initial events. If rollback is what the protocol implies than there will be more complications if embedded commands were to be treated as atomic. Regards, Hemant ------------------------------------------------ Hemant Kumar Ficon Technology E-mail: mailto:hkumar@ficon-tech.com Web: http://www.ficon-tech.com ------------------------------------------------ ------_=_NextPart_001_01BF958F.DCACE5E6 Content-Type: text/html; charset="iso-8859-1"
Hemant
 
Yes, it implies rollback, although I wouldn't implement it that way (I'd allocate all the resources, then make the state changes).
 
At some point, you have a balance between discriminating errors and ease of implementation, as well as one between the complexity of the syntax and ease of
implementation.
 
If we were to say that the descriptors are executed in order, and errors can occur
at any descriptor, then what about your example where the signals descriptor contains
two signals, the first is okay, but the second fails?  Should we remove the first?
That's atomicity of descriptors.  Should we allow sequential execution of elements
in a descriptor or force "rollback" within the descriptor?
 
Please do keep in mind that I advocated atomicity of transactions, and was in a
distinct minority.
 
Brian
 
-----Original Message-----
From: Hemant [mailto:hkumar@ficon-tech.com]
Sent: Friday, March 24, 2000 6:31 AM
To: MEGACO@standards.nortelnetworks.com
Subject: Re: Descriptor processing order

Hi,
 
     I wish to have some clarification on the issue of command being atomic.
Does this imply that if an activity has been initiated by the MG in response to a command and subsequently a failure occurs during its processing, the MG should rollback all actions that have happened till that point in the command (in which error has occurred).
 
For e.g.
- The MG is looking for some Events on a particular termination
- A modify command containing another event desc. and signal desc. is received for that termination (Descriptors in that order)
- The events are configured in the MG ( acc. to the new event desc.)
- Error is encountered in the MG while allocation of the resources for generating signals
- Rollback implies that the MG stop looking the current event and again start looking for the initial events.
 
If rollback is what the protocol implies than there will be more complications if embedded commands were to be treated as atomic.
 
Regards,
Hemant

------------------------------------------------
Hemant Kumar
Ficon Technology
E-mail: mailto:hkumar@ficon-tech.com
Web: http://www.ficon-tech.com
------------------------------------------------
------_=_NextPart_001_01BF958F.DCACE5E6-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 24 08:48:57 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21078 for ; Fri, 24 Mar 2000 08:48:55 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D8E1B360@standards.nortelnetworks.com>; Fri, 24 Mar 2000 8:42:11 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 101722 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 24 Mar 2000 08:41:18 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B8F984B0@standards.nortelnetworks.com>; Fri, 24 Mar 2000 8:41:18 -0500 Received: from chsharp-tecra.cisco.com (chsharp-isdn.cisco.com [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id FAA19298; Fri, 24 Mar 2000 05:45:49 -0800 (PST) X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.1.2.20000324082122.00b06410@dogwood.cisco.com> Date: Fri, 24 Mar 2000 08:24:59 -0800 Reply-To: Chip Sharp Sender: "Media Gateway Control (megaco)" From: Chip Sharp Subject: Re: Conversion errors in draft-ietf-megaco-protocol-07.txt X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4FBEA8857476D311A03300204840E1CF208B80@whq-msgusr-02.fore. com> Brian and John must be the world's experts for ITU to IETF conversion Word macros by now. :-) In any case, for better or worse the text version is the definitive version for IETF. Chip At 07:42 AM 3/24/00 -0500, Rosen, Brian wrote: >We must publish .txt files for the IETF process. I've been using >the same tools since the first draft was published, and no one >has pointed out any errors other than some table formatting, >and a few missed directives. > >I will look into the problem, and have it fixed for the RFC. >I'd suggest you use the .doc or .pdf files in most cases, as they >are more readable, but I have spent many hours making the .txt >files for those who want them, and aim to have them be as accurate >as possible. > >The last draft was rushed, so it's possible that I did something >wrong there. > >At any rate, I apologize, and will have this particular problem >cleaned up for whatever comes next. If you spot anything else, >please let me know. > >Brian > > > -----Original Message----- > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > Sent: Friday, March 24, 2000 4:20 AM > > To: MEGACO@standards.nortelnetworks.com > > Subject: Conversion errors in draft-ietf-megaco-protocol-07.txt > > > > > > Hello, > > > > The current I-D draft-ietf-megaco-protocol-07.txt is > > missing some > > text found in the word/PDF files. Some special > > characters, like > > backslash "\", seem to be confusing the software > > converting the word > > file. The lossage is worst in the appendix specifying > > the ABNF, i.e. > > the IETF-specific part of the spec. > > > > Unless the conversion errors are fixed, the errors make > > draft-ietf-megaco-protocol-07.txt (and the Proposed > > Standard based > > on it) quite useless as a basis for implementation. I > > mean, one has > > to check every detail with the PDF/Word files. > > > > So, I wonder, that is the point here publishing > > draft-ietf-megaco-protocol-07.txt? > > > > Regards, > > Pekka Pessi > > http://www.netaid.org ------------------------------------------------------------------------- Chip Sharp CTO Consulting Engineering Cisco Systems Reality - Love it or Leave it. ------------------------------------------------------------------------ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 24 10:47:35 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02341 for ; Fri, 24 Mar 2000 10:47:35 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A2547D80@standards.nortelnetworks.com>; Fri, 24 Mar 2000 10:42:21 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 101841 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 24 Mar 2000 10:41:18 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7C60EA00@standards.nortelnetworks.com>; Fri, 24 Mar 2000 10:41:17 -0500 Received: from chsharp-tecra.cisco.com (chsharp-isdn.cisco.com [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id HAA14177; Fri, 24 Mar 2000 07:45:49 -0800 (PST) X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.1.2.20000324102207.00c2c610@dogwood.cisco.com> Date: Fri, 24 Mar 2000 10:31:33 -0800 Reply-To: Chip Sharp Sender: "Media Gateway Control (megaco)" From: Chip Sharp Subject: Re: V16 review - events Descriptor X-To: Nancy-M Greene To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: At 02:29 PM 3/23/00 -0600, Nancy-M Greene wrote: >This comment is editorial, trying to improve the clarity of section 7.1.9: > >(and, it is, I hope, our last comment on v16 :-) ) > >Section 7.1.9 Events Descriptor >Issue: Case 1, item 2a), and Case 2 are not yet completely clear. >Case 1, item 2a) currently says: >"... detected. The MG then waits for a new EventsDescriptor. While waiting >for a new EventsDescriptor, any events matching the EventsBufferDescriptor >will be placed in the EventBuffer and the event processing will repeat from >step 1." > >Proposal: >i) Change "While waiting..." sentence in Case 1, item 2a) to be: >"While waiting for a new EventsDescriptor, any events detected which >appear in the current EventsBufferDescriptor will be placed in the >EventBuffer. >When a new EventDescriptor is received, event processing repeats >from step 1." Yes. The current text is clearly incorrect. If implemented exactly as it currently says, I believe it would cause an infinite loop. The text above reflects the original intent in TD-85 from Geneva. I also think this should be in the errata for H.248 in June since it is an important technical correction. BTW, the formatting of this section in draft-ietf-megaco-protocol-07.txt is not correct. >ii) and add this sentence to Case 2: >"Events detected that match an event in the new EventsDescriptor are >immediately notified." I believe we had a statement like this originally, but it was removed since it was redundant with the sentance at the beginning of the section: "The MG shall send a Notify command to the MGC when it detects an event in the Events Descriptor." The statement you suggest is a true statement. I tend to think redundant encoding in this section would be helpful. :-) Again, the formatting of this section is incorrect. The current text in version 7 implies that all the text following "Case 2" is part of Case 2 when in fact it is only the sentence immediately following the words "Case 2" plus the above if it is added. >Nancy >Abdallah > >-------------------------------------------------------------------------- >Nancy M. Greene >Internet & Service Provider Networks, Nortel Networks >T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com http://www.netaid.org ------------------------------------------------------------------------- Chip Sharp CTO Consulting Engineering Cisco Systems Reality - Love it or Leave it. ------------------------------------------------------------------------ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 24 11:43:51 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21141 for ; Fri, 24 Mar 2000 11:43:49 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7890FCA0@standards.nortelnetworks.com>; Fri, 24 Mar 2000 11:38:27 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 101917 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 24 Mar 2000 11:37:09 -0500 Received: from smtprtp.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4A1F0880@standards.nortelnetworks.com>; Fri, 24 Mar 2000 11:37:09 -0500 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp.ntcom.nortel.net; Fri, 24 Mar 2000 11:40:52 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 24 Mar 2000 11:40:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF95AF.B60CF582" Message-ID: Date: Fri, 24 Mar 2000 11:40:47 -0500 Reply-To: Nancy-M Greene Sender: "Media Gateway Control (megaco)" From: Nancy-M Greene Subject: Re: V16 review - Editorial comments 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_01BF95AF.B60CF582 Content-Type: text/plain; charset="iso-8859-1" Hi Christian, thanks for your comments. My comments are below. The goal as always, is to change the spec only if necessary. Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > ---------- > From: Christian Groves[SMTP:Christian.Groves@ERICSSON.COM] > Sent: Wednesday, March 22, 2000 10:29 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: V16 review - Editorial comments > > G'Day Nancy, > > Please see my comments marked [CHG]. > > Cheers, Christian > > Nancy-M Greene wrote: > > > > Brian, John, > > I believe each of the following is an editorial change to V16. You > > have both seen most of these already, and commented on them - I am > > posting them to the megaco list this time, with the proposed > > resolutions. Please comment! > > > > 1- Section 7.1.1 Specifying Parameters > > Issue: para. starting with "Unspecified mandatory parameters > > (i.e. mandatory parameters not specified in a descriptor) result > > in the command responder retaining the previous value for that > > parameter." > > > > Comment: It seems that this section applies only to mandatory fields > > in > > Local and Remote descriptors (see section 7.1.8). For example, when > > a mandatory parameter is unspecified in the Local descriptor, > > then it retains the value it already has. But, a mandatory parameter > > in a ServiceChange HAS to be there I would think. For example, the > > ServiceChangeMethod descriptor is mandatory, and must > > always be present. > > > > Proposal: Preface the quoted sentence in 7.1.1 with "For Local and > > Remote Descriptors, unspecified mandatory parameters (i.e. mandatory > > parameters not specified in a descriptor) result in the ...." > > > > 2- Section 7.1.6 Stream Descriptor > > Issue: last sentence of first para, "A stream is deleted by > > setting empty Local and Remote descriptors for the stream with > > ReserveGroup and ReserveValue in LocalControl set to "false" on > > all terminations in the context that previously supported that > > stream." > > > > Comment: We don't have false or true in the ABNF, only "ON/OFF". The > > text uses both true/false, and on/off. > > > > Proposal: Make no changes to the text. Just add this comment: > > "ON = true, and OFF = false" to the ABNF. > [CHG] OK > > > > > 3- Section 7.1.7 LocalControl Descriptor - ReserveGroup/ReserveValue > > Issue: There is no explanation as to what ReserveValue and > > ReserveGroup mean. > > > > Proposal: Add text something like the following: > > "In order to state that one session description is to be selected > > out of a list, ReserveGroup is set to "false". If resources for all > > session descriptions are to be reserved, ReserveGroup is set > > to "true". In order to state that a parameter with a list of values, > > e.g. multiple rtp payload types, requires one value is to be > > selected from the list, ReserveValue is set to "false". If resources > > for all values are to be reserved, ReserveValue is set to "true". > > In other words, overspecifying by giving a list of values can happen > > independently at the session description level and at the parameter > > level. " > [CHG] I don't think this is necessary. The text currently states: "The > boolean-valued Reserve properties, ReserveValue and ReserveGroup" and > then it follows in the next 2 paragraphs about what to do. The terms > value and groups are used in other sections. This isn't an error at best > its something for a possible implementors guide. > [Nancy] You are right, there is some text there. If necessary, some of our text can be added for clarification - I will leave it up to the editors. > > > > 4- Section 7.1.9 Events Descriptor - eventDM > > Issue: eventDM is not mentioned in this section while it is part of > > the > > eventsDescriptor syntax. > > > > Proposal: Add this sentence: > > "If a digit map is required in the EventsDescriptor, EventDM is used > > to carry either the name or the value of the digit map. See > > section 7.1.14." > > > > 5- Section 7.1.11 Signals Descriptor > > Issue: setting of the signal list type > > > > Proposal: Add the following to section 7.1.11: > > * on/off in signal list > > -> it must be the last element, and signal list type must be > > on/off > > * timeout in signal list (and NO on/off signals in the list) > > -> signal list type must be timeout > > * only brief signals in signal list > > -> signal list type defaults to brief. > > [CHG] Isn't this in the determined draft? 2nd paragraph after list. > [Nancy] Yes it is there in the 2nd paragraph after the list. Our proposal is to clarify that paragraph. If people understand it as it is written, then we don't need to add our text. > > > > 6- Section 7.1.12 Audit Descriptor, and also auditItem in the ABNF > > Issue: the last entry in the table is "EventBuffer". auditItem in the > > ABNF > > does not qualify it either which is incorrect. > > > > Proposal: Change "EventBuffer" to "EventBuffer Descriptor" in both > > section 7.1.12 > > and in the ABNF. > > > > 7- Section 7.1.13 ServiceChangeDescriptor > > Issue: Extension is not part of the enumeration > > > > Comment: Is ServiceChangeDescriptor supposed to be extendable or not? > > The ABNF still has an extension parameter in it. > [CHG] I don't like the extension parameter but we do have it. See 7.2.8 > no.7 in the list. And the text in 7.2.8 "The optional Extension > parameter may contain any value whose meaning is mutually understood by > the MG and MGC." > > > > > 8- Section 7.1.18 Topology Descriptor > > Issue: para starting with "(T1,T2, bothway) means that .... > > loopbacks are created by setting the TerminationMode." > > > > Comment: We don't have TerminationMode any more. > > > > Proposal: change it to read: > > "...loopbacks are created by setting the StreamMode property to > > LoopBack > > in the LocalControlDescriptor." > [CHG] Perhaps we can just delete the text after the ";"? StreamMode = > Loopback is in 7.1.7 > [Nancy] your proposal is fine. > > > > 9- 7.2.5 Audit Value > > Issue "W-" and "O-" > > Comment: Text does not describe that wildcarded response > > is qualified by "W-". Also, no text explaining that > > optional commands are qualified by "O-". > > > > Proposal: in section 7.2.5, add the following: > > "The wildcard response option (see section 6.2.2) is particularly > > useful > > to limit the size of a n audit value command which uses a wildcard > > terminationId. In ASN.1 encoding (Annex A), the flag "wildcardReturn" > > is set on a command, and in ABNF (Annex B), the command is qualified > > by the "W-" option." > > [CHG] Sect 6.2.2 already covers much of this. I don't see a need to > repeat the information in 7.2.5. 6.2.2 even recommends that this is > useful for audit. > [Nancy] All right, the first sentence can go. BUT, we need the text that explains O- and W-, and the corresponding ASN.1 terms "wildcardReturn" and "optional". > > > > Also, in section 8, add the following: > > "In ASN.1 encoding, the flag "optional" is set on a command, and in > > the > > ABNF, the command is qualified with the "O-" option." > > > > 10- Section 7.2.6 AuditCapabilities > > Issue: AuditCapability API > > > > Comment: same as in 9-Section 7.2.5 > > > > Proposal: Add same sentences as above, to this section. > > > [CHG] See my comment on 7.2.5 > > > 11- Section 7.2.6 AuditCapabilities - DigitMap and Packages > > Issue: DigitMap and Packages in the ABNF > > > > Comment: The ABNF allows DigitMap and Packages > > in the return of AuditCapability. The text says no. Need to > > add a comment in the ABNF that explains this. > > > > Proposal: Add the following comment to the ABNF: > > "DigitMap and Packages are not permitted to be part of > > AuditCapabilities" > > > > 12- ANNEX B: signalListParm > > Issue: signalListParm = signalRequest > > > > Comment: This is redundant. > > > > Proposal: in the ABNF, signalRequest should replace > > signalListParm in signalList. > > > > 13- ANNEX B:digitMapValue > > Issue: digitMapDescriptor = DigitMapToken EQUAL digitMapName > > ( LBRKT digitMapValue RBRKT ) > > > > Comment: error with the round brackets > > > > Proposal: it should be > > digitMapDescriptor = DigitMapToken EQUAL digitMapName > > [ LBRKT digitMapValue RBRKT ] > > > > 14- ANNEX B: version token > > Issue: VersionToken is missing in the ABNF. > > > > Proposal: Add VersionToken = ("Version" / "V") > > > > Nancy & Abdallah > > > > > -------------------------------------------------------------------------- > > > > Nancy M. Greene > > Internet & Service Provider Networks, Nortel Networks > > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > ------_=_NextPart_001_01BF95AF.B60CF582 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: V16 review - Editorial comments

Hi Christian, thanks = for your comments. My comments are below. The goal as always, is to = change the spec only if necessary.

Nancy
-----------------------------------------------------------------= ---------
Nancy M. Greene
Internet & Service = Provider Networks, Nortel Networks
T:514-271-7221 = (internal:ESN853-1077) E:ngreene@nortelnetworks.com

    ----------
    From:   = Christian = Groves[SMTP:Christian.Groves@ERICSSON.COM]
    Sent:   = Wednesday, March 22, 2000 10:29 = PM
    To: =     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject: =        Re: V16 review - Editorial comments

    G'Day Nancy,

    Please see my comments marked = [CHG].

    Cheers, Christian

    Nancy-M Greene wrote:
    >
    > Brian, John,
    > I believe each of the following = is an editorial change to V16. You
    > have both seen most of these = already, and commented on them - I am
    > posting them to the megaco list = this time, with the proposed
    > resolutions. Please = comment!
    >
    > 1- Section 7.1.1 Specifying = Parameters
    > Issue: para. starting with = "Unspecified mandatory parameters
    > (i.e. mandatory parameters not = specified in a descriptor) result
    > in the command responder = retaining the previous value for that
    > parameter."
    >
    > Comment: It seems that this = section applies only to mandatory fields
    > in
    > Local and Remote descriptors = (see section 7.1.8). For example, when
    > a mandatory parameter is = unspecified in the Local descriptor,
    > then it retains the value it = already has. But, a mandatory parameter
    > in a ServiceChange HAS to be = there I would think. For example, the
    > ServiceChangeMethod descriptor = is mandatory, and must
    > always be present.
    >
    > Proposal: Preface the quoted = sentence in 7.1.1 with "For Local and
    > Remote Descriptors, unspecified = mandatory parameters (i.e. mandatory
    > parameters not specified in a = descriptor) result in the ...."
    >
    > 2- Section 7.1.6 Stream = Descriptor
    > Issue: last sentence of first = para, "A stream is deleted by
    > setting empty Local and Remote = descriptors for the stream with
    > ReserveGroup and ReserveValue in = LocalControl set to "false" on
    > all terminations in the context = that previously supported that
    > stream."
    >
    > Comment: We don't have false or = true in the ABNF, only "ON/OFF". The
    > text uses both true/false, and = on/off.
    >
    > Proposal: Make no changes to the = text. Just add this comment:
    > "ON =3D true, and OFF =3D = false" to the ABNF.
    [CHG] OK

    >
    > 3- Section 7.1.7 LocalControl = Descriptor - ReserveGroup/ReserveValue
    > Issue: There is no explanation = as to what ReserveValue and
    > ReserveGroup mean.
    >
    > Proposal: Add text something = like the following:
    > "In order to state that one = session description is to be selected
    > out of a list, ReserveGroup is = set to "false". If resources for all
    > session descriptions are to be = reserved, ReserveGroup is set
    > to "true". In order to = state that a parameter with a list of values,
    > e.g. multiple rtp payload types, = requires one value is to be
    > selected from the list, = ReserveValue is set to "false". If resources
    > for all values are to be = reserved, ReserveValue is set to "true".
    > In other words, overspecifying = by giving a list of values can happen
    > independently at the session = description level and at the parameter
    > level. "
    [CHG] I don't think this is = necessary. The text currently states: "The
    boolean-valued Reserve properties, = ReserveValue and ReserveGroup" and
    then it follows in the next 2 = paragraphs about what to do. The terms
    value and groups are used in other = sections. This isn't an error at best
    its something for a possible = implementors guide.

[Nancy] You are = right, there is some text there. If necessary, some of our text can be = added for clarification - I will leave it up to the editors.

    >
    > 4- Section 7.1.9 Events = Descriptor - eventDM
    > Issue: eventDM is not mentioned = in this section while it is part of
    > the
    > eventsDescriptor syntax.
    >
    > Proposal: Add this = sentence:
    > "If a digit map is required = in the EventsDescriptor, EventDM is used
    > to carry either the name or the = value of the digit map. See
    > section 7.1.14."
    >
    > 5- Section 7.1.11 Signals = Descriptor
    > Issue: setting of the signal = list type
    >
    > Proposal: Add the following to = section 7.1.11:
    > * on/off in signal list
    >     -> it = must be the last element, and signal list type must be
    > on/off
    > * timeout in signal list (and NO = on/off signals in the list)
    >      = -> signal list type must be timeout
    > * only brief signals in signal = list
    >     -> = signal list type defaults to brief.

    [CHG] Isn't this in the determined = draft? 2nd paragraph after list.

[Nancy] Yes it is = there in the 2nd paragraph after the list. Our proposal is to clarify = that paragraph. If people understand it as it is written, then we don't = need to add our text.

    >
    > 6- Section 7.1.12 Audit = Descriptor, and also auditItem in the ABNF
    > Issue: the last entry in the = table is "EventBuffer". auditItem in the
    > ABNF
    > does not qualify it either which = is incorrect.
    >
    > Proposal: Change = "EventBuffer" to "EventBuffer Descriptor" in = both
    > section 7.1.12
    > and in the ABNF.
    >
    > 7- Section 7.1.13 = ServiceChangeDescriptor
    > Issue: Extension is not part of = the enumeration
    >
    > Comment: Is = ServiceChangeDescriptor supposed to be extendable or not?
    > The ABNF still has an extension = parameter in it.
    [CHG] I don't like the extension = parameter but we do have it. See 7.2.8
    no.7 in the list. And the text in = 7.2.8 "The optional Extension
    parameter may contain any value whose = meaning is mutually understood by
    the MG and MGC."

    >
    > 8- Section 7.1.18 Topology = Descriptor
    > Issue: para starting with = "(T1,T2, bothway) means that ....
    > loopbacks are created by setting = the TerminationMode."
    >
    > Comment: We don't have = TerminationMode any more.
    >
    > Proposal: change it to = read:
    > "...loopbacks are created = by setting the StreamMode property to
    > LoopBack
    > in the = LocalControlDescriptor."
    [CHG] Perhaps we can just delete the = text after the ";"? StreamMode =3D
    Loopback is in 7.1.7

[Nancy] your = proposal is fine.

    >
    > 9- 7.2.5 Audit Value
    > Issue "W-" and = "O-"
    > Comment: Text does not describe = that wildcarded response
    > is qualified by "W-". = Also, no  text explaining that
    > optional commands are qualified = by "O-".
    >
    > Proposal: in section  = 7.2.5, add the following:
    > "The wildcard response = option (see section 6.2.2) is particularly
    > useful
    > to limit the size of a n audit = value command which uses a wildcard
    > terminationId. In ASN.1 encoding = (Annex A), the flag "wildcardReturn"
    > is set on a command, and in ABNF = (Annex B), the command is qualified
    > by the "W-" = option."

    [CHG] Sect 6.2.2 already covers much = of this. I don't see a need to
    repeat the information in 7.2.5. = 6.2.2 even recommends that this is
    useful for audit.

[Nancy] All right, = the first sentence can go. BUT, we need the text that explains O- and = W-, and the corresponding ASN.1 terms "wildcardReturn" and = "optional".

    >
    > Also, in section 8, add the = following:
    > "In ASN.1 encoding, the = flag "optional" is set on a command, and in
    > the
    > ABNF, the command is qualified = with the "O-" option."
    >
    > 10- Section 7.2.6 = AuditCapabilities
    > Issue: AuditCapability = API
    >
    > Comment: same as in 9-Section = 7.2.5
    >
    > Proposal: Add same sentences as = above, to this section.
    >
    [CHG] See my comment on 7.2.5

    > 11- Section 7.2.6 = AuditCapabilities - DigitMap and Packages
    > Issue: DigitMap and Packages in = the ABNF
    >
    > Comment: The ABNF allows = DigitMap and Packages
    > in the return of = AuditCapability. The text says no. Need to
    > add a comment in the ABNF that = explains this.
    >
    > Proposal: Add the following = comment to the ABNF:
    > "DigitMap and Packages are = not permitted to be part of
    > AuditCapabilities"
    >
    > 12- ANNEX B: = signalListParm
    > Issue: signalListParm =3D = signalRequest
    >
    > Comment: This is = redundant.
    >
    > Proposal: in the ABNF, = signalRequest should replace
    > signalListParm in = signalList.
    >
    > 13- ANNEX B:digitMapValue
    > Issue: digitMapDescriptor =3D = DigitMapToken EQUAL digitMapName
    > ( LBRKT digitMapValue RBRKT = )
    >
    > Comment: error with the round = brackets
    >
    > Proposal: it should be
    > digitMapDescriptor =3D = DigitMapToken EQUAL digitMapName
    > [ LBRKT digitMapValue RBRKT = ]
    >
    > 14- ANNEX B: version = token
    > Issue: VersionToken is missing = in the ABNF.
    >
    > Proposal: Add VersionToken =3D = ("Version" / "V")
    >
    > Nancy & Abdallah
    >
    > = ------------------------------------------------------------------------= --
    >
    > Nancy M. Greene
    > Internet & Service Provider = Networks, Nortel Networks
    > T:514-271-7221 = (internal:ESN853-1077) E:ngreene@nortelnetworks.com

------_=_NextPart_001_01BF95AF.B60CF582-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 24 13:14:00 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23873 for ; Fri, 24 Mar 2000 13:14:00 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.10A7F5F0@standards.nortelnetworks.com>; Fri, 24 Mar 2000 13:08:36 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 102032 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 24 Mar 2000 13:07:35 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EC06FA20@standards.nortelnetworks.com>; Fri, 24 Mar 2000 13:07:35 -0500 Received: from chsharp-tecra.cisco.com (chsharp-isdn.cisco.com [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id KAA16474; Fri, 24 Mar 2000 10:12:06 -0800 (PST) X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.1.2.20000324124223.00bdfe30@dogwood.cisco.com> Date: Fri, 24 Mar 2000 12:50:29 -0800 Reply-To: Chip Sharp Sender: "Media Gateway Control (megaco)" From: Chip Sharp Subject: Re: V16 review - Editorial comments X-To: Nancy-M Greene To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: At 08:35 PM 3/20/00 -0600, Nancy-M Greene wrote: ...snip... >6- Section 7.1.12 Audit Descriptor, and also auditItem in the ABNF >Issue: the last entry in the table is "EventBuffer". auditItem in the ABNF >does not qualify it either which is incorrect. > >Proposal: Change "EventBuffer" to "EventBuffer Descriptor" in both section >7.1.12 >and in the ABNF. Nit. I don't think there should be a space between "EventBuffer" and "Descriptor." ...snip... http://www.netaid.org ------------------------------------------------------------------------- Chip Sharp CTO Consulting Engineering Cisco Systems Reality - Love it or Leave it. ------------------------------------------------------------------------ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 24 20:52:31 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07506 for ; Fri, 24 Mar 2000 20:52:30 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.269C6E00@standards.nortelnetworks.com>; Fri, 24 Mar 2000 20:47:21 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 102404 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 24 Mar 2000 20:46:19 -0500 Received: from pop-rocks.shoretel.com (208.163.34.3) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9BEF7140@standards.nortelnetworks.com>; Fri, 24 Mar 2000 20:36:19 -0500 Received: by pop-rocks.shoretel.com with Internet Mail Service (5.5.2650.21) id ; Fri, 24 Mar 2000 17:41:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <1A1B8F0BB483D311B139005004744834402732@pop-rocks.shoretel.com> Date: Fri, 24 Mar 2000 17:40:51 -0800 Reply-To: Jeff Ridley Sender: "Media Gateway Control (megaco)" From: Jeff Ridley Subject: Re: Interop > Re: Proposal: explain MEGACO protocol RFC status ex plicitly To: MEGACO@STANDARDS.NORTELNETWORKS.COM Christian, I can definitely see the point of a protocol focused test suite. I believe this represents a good first step in that it isolates the protocol issues that may be discovered in initial design work. I would suggest that this level of inter-operability testing be focused on the basics. If such a test profile were available, it would represent a good milestone to check any design work prior to the complexities of the application being introduced. In short it could help validate some protocol efforts but also becomes a reference or tool for future work. There would be some work of course, to determine how good a test could be devised that remained neutral to target applications. The next step is the movement toward applications. In parallel to define a protocol test profile, profiles can also be defined so there is a quick migration to complete applications. I would believe we should select one/a few applications and begin to develop the profiles with a target to host application interoperability testing. Jeff -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] Sent: Thursday, March 23, 2000 4:47 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Interop > Re: Proposal: explain MEGACO protocol RFC status explicitly G'Day Pete, I am proposing that a test suite is a first step towards more of a full interop test. I think that to satisfy IETF requirements what we need is a simple protocol test. Applications such as Tiphon, IP phones, MSF, BICC etc are best interop tested as a whole in the relevant organisations. These depend on several elements working ie. RTP stack, codecs, etc. Real applications are of course the aim at the end of the day but we need to start somewhere. My 5c worth (we don't 1 or 2 cent coins in OZ) Cheers, Christian Peter Blatherwick wrote: > > I like the idea of a test suite. It would allow us to quickly verify > the basic mechanics in an agnostic way. This would not test the > specific packages, which of course also need to be interoped, and > would not be a "test in practice". Of course designing the suite > would take some time. > > I still believe that deciding some simple, real, applications would be > a VERY good step as well, real soon. Test suite would be an initial > step only in my mind. Real applications is what we're trying to get > to after all, and we'll learn a lot more about the practical aspects > through these. > > My 0.02. (How much is that in Oz dollars, converted from Canadian?) > > -- Peter > > -----Original Message----- > From: Christian Groves [SMTP:Christian.Groves@ERICSSON.COM] > Sent: 23 Mar, 2000 01:01 > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Interop > Re: Proposal: explain MEGACO > protocol RFC status explicitly > > G'Day Brian, > > Thanks for the update. Can you elaborate on the "home" of this > effort? I > know you've done some work in MSF on this. Can you provide some > info to > the list if you have more details of what is to be tested and > what the > current plans are? > > Is it necessary to organise a "home" for this effort? Sigtran it > seems > are doing a protocol interop test without having to go to another > forum. > Interested parties are getting together. Perhaps someone who > participates in the Sigtran interop can comment? Perhaps we could > do > something similar for Megaco? > > I'm glad that the first step with not be part of a larger effort > and > will be done on simple devices. The question is what sort of > devices and > what packages? > > I've envisaged that the test could be done as you say between > Megaco MGC > and Megaco MG and would be agnostic of the application and many > packages. I saw that we test the root package as it has protocol > specific information and perhaps a specifically developed test > package > that has a number of properties, signals, events, statistics > labelled in > a very generic way. I didn't see that we would do a simple IP > phone or > trunking GW interop. After all we just need to test the Megaco > mechanisms. > > A test profile containing test cases and scripts could then be > defined > to test the various protocol mechanism employed to relay the > properties, > signals, events and statistics. > > We can worry about format and reporting of the interop event when > we get > closer to it. > > Cheers, Christian > > "Rosen, Brian" wrote: > > > > I have been planning to (help) organize early interoperability > > testing. There is some experience in PacketCable and ISC > > in testing MGCP that we can leverage. > > > > I have been looking for a "home" for this effort, and hope > > to have that worked out soon. > > > > I believe the first testing will NOT be part of a larger > testing > > effort, and we will pair Megaco MGCs with Megaco MGs for > testing. > > First tests will be done with "simple" devices - no more than > > a subset of the packages defined in the original document. > > We may have a test profile to offer well in advance of the test > > > that will improve the probability of many MGCs and MGs to try. > > There will be some scripts available. > > > > It will be open to all who have devices to test. It will be > > "private" - no observers, just engineer to engineer. The only > > reports issued will be summary in nature and limited to areas > > of confusion or other protocol documentation issues. > > > > I'd like to hear from people implementing the protocol when > they > > would be ready to start testing. I may have a "co-sponsor", > > but others are welcome if they are interested. > > > > Brian > > > > > -----Original Message----- > > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > > > > Sent: Tuesday, March 21, 2000 10:27 PM > > > To: MEGACO@standards.nortelnetworks.com > > > Subject: Interop > Re: Proposal: explain MEGACO protocol RFC > status > > > explicitly > > > > > > > > > G'Day all, > > > > > > Chip raises an interesting issue of interoperability tests. > > > The current > > > plans for such testing seems to me to be ambiguous at best. > > > > > > Due to the generic nature of Megaco it seems to me to be > > > quite difficult > > > to test. From what I have seen (please correct me if this > isn't the > > > case) is that Megaco/H248 is planned to be tested as part of > a larger > > > application test. ie. trunking gateway, IP phone etc. This to > > > > me seems a > > > lot of overhead just to test the megaco protocol. It also > seems to put > > > certain players of the interop test. ie. if I make SIP GW > which have > > > h248 but the interop test covers IP phones how do I get my > > > Megaco stack > > > tested??? > > > > > > Are there any initiatives where something similar to the > following > > > approach is taken? Do people see merit in this? > > > o The test is a test of the protocol mechanisms. > > > o Test between 2 boxes (PCs, workstations etc) that implement > > > > H248 with > > > the necessary SW to drive the test. These boxes would be > application > > > agnostic. > > > o A test package could be developed with "dummy" properties, > events, > > > signals etc. > > > o A test case document which lists test cases for a good > coverage test > > > of Megaco. These test cases could describe what should occur > at dummy > > > event detection. > > > > > > The aim of the approach is an interop where people who intend > to > > > implement Megaco but not in one of the proposed applications > can test > > > there stacks without having to implement an entire > application. > > > > > > If anyone has any information of the current status of Megaco > interops > > > can they please share it on the list. > > > > > > Cheers, Christian > > > > > > > > > Chip Sharp wrote: > > > > > > > > As a further clarification, independent of any judgement on > > > > megaco/H.248 in > > > > particular, publication of any RFC as Proposed Standard is > really a > > > > snapshot of the development of the protocol. At the point > > > of publication > > > > of the RFC as Proposed Standard, the protocol is considered > > > > stable enough > > > > to begin implementation, perform interoperability tests and > > > > perhaps get > > > > some deployment experience (not necessarily in production > networks). > > > > > > > > If during this process, problems are found in the protocol > > > and corrections > > > > are needed, a new RFC can be published with the corrections > > > > while still > > > > remaining in Proposed Standard state. > > > > > > > > There is no requirement to implement an I-D before it moves > > > > to Proposed > > > > Standard. Sometimes this is done and it definitely helps > > > to get this > > > > experience to learn the ins and outs as the protocol is > > > developed, but it > > > > is not required. > > > > > > > > As far as megaco/H.248 is concerned, I do believe something > like > > > > implementer's agreements (or profiles) will have to be > > > worked out for > > > > interoperability reasons for specific applications since > > > there are so many > > > > options and different ways of doing the same thing. > > > Although there are > > > > details we all don't agree on, the IP Phone profile is one > > > attempt at doing > > > > this for an IP Phone application. > > > > > > > > One thing to keep in mind is that before megaco can move to > > > > Draft Standard > > > > in IETF, all options that don't have multiple interoperable > > > > implementations > > > > have to be removed. > > > > > > > > Chip > > > > > > > > At 08:50 AM 3/21/00 -0500, Rosen, Brian wrote: > > > > >I disagree with your assessment of the state of the > protocol. > > > > > > > > > >While there have been a series of text change proposals > made > > > > >in the last few weeks, all of them have either been > requests > > > > >to clear up language, or proposals to fix some minor > errors for > > > > >unusual circumstances. In no case, AFAIK, would any of > the changes > > > > >invalidate any existing implementation by more than a very > minor > > > > >addition. There are no plans for any major changes to > syntax, > > > > >and no changes at all to semantics, unless you consider > > > clarification > > > > >of intent to be a semantic change. I don't understand the > > > > "transport > > > > >syntax" part at all, unless you are thinking about the ITU > work > > > > >on ATM transport and SCTP annexes, which will not carry > > > through to the > > > > >IETF version on present plans. > > > > > > > > > >There will be an erratum published with the RFC. > Together, they > > > > >should provide a stable basis for the protocol. The > > > document is large. > > > > >In any such document, there are things that could use more > > > > explanation. > > > > >While an implementor's guide has been discussed, it has > not yet > > > > >been decided if we will need one. I suspect we will. The > > > > guide will > > > > >not, if I have anything to do with it, change the protocol > at all. > > > > >If it needs to be changed, we will have to have a new RFC. > > > > > > > > > > >Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > > > > > Sent: Tuesday, March 21, 2000 8:35 AM > > > > > > To: MEGACO@standards.nortelnetworks.com > > > > > > Subject: Proposal: explain MEGACO protocol RFC status > explicitly > > > > > > > > > > > > > > > > > > Hello all, > > > > > > > > > > > > The current MEGACO/H.248 draft, > > > > > > draft-ietf-megaco-protocol-07.txt, > > > > > > is still ongoing work. AFAIK the protocol is > still > > > > > > incomplete and > > > > > > largely unimplementable. A reference > implementation > > > > > > has just been > > > > > > started. The working group is planning to > > > change the protocol > > > > > > semantics and transport syntax. There would be > > > no point in > > > > > > publishing the document as an RFC, if this were > an > > > > > > IETF-only project > > > > > > > > > > > > As I have understood, publishing incomplete > > > recommendations is > > > > > > business as usual in ITU-T due to practical > > > reasons. The ITU-T > > > > > > recommendations must be approved using > > > time-consuming formal > > > > > > process, including a ballot. So, the finalized > ITU-T > > > > > > specification > > > > > > actually consists of a recommendation document > > > > > > together with an > > > > > > Implementor's Guide correcting the errors and > > > omissions in the > > > > > > recommendation document. IG may contain major > > > changes that are > > > > > > incompatible with the published recommendation > > > > > > document. Also, when > > > > > > referring to a ITU-T specification, like > > > H.323v2, people are > > > > > > actually referring to the recommendation > > > together with the > > > > > > respective implementor's guide. > > > > > > > > > > > > The ITU-T process is (or at least should be) > > > familiar to the > > > > > > developers using ITU-T recommendations. > > > However, in Internet > > > > > > community people are expecting that the RFC is > not > > > > > > just a snapshot > > > > > > of an on-going work. They don't anticipate that > there > > > > > > is a companion > > > > > > document possibly changing the base protocol in > > > > every turn. > > > > > > > > > > > > Proposal > > > > > > > > > > > > I propose that the MEGACO RFC should contain a > > > > > > paragraph explaining > > > > > > the status of the text, ie. that the protocol > will be > > > > > > changed by an > > > > > > Implementors' Guide published soon. The MEGACO > > > RFC should also > > > > > > recommend that any reference to it must also be > > > > > > > accompanied with a > > > > > > note explaining the status of the RFC, and a > > > reference to the > > > > > > Implementors' Guide. > > > > > > > > > > > > Best regards, > > > > > > Pekka Pesi > > > > > > > > > > > > > > Support NetAid! http://www.netaid.org > > > > -------------------------------------------------- > > > > Chip Sharp Consulting Engineering > > > > Cisco Systems Telco Bio-region > > > > Reality - Love it or Leave it. > > > > -------------------------------------------------- > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sat Mar 25 12:06:01 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21943 for ; Sat, 25 Mar 2000 12:06:00 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C1137B20@standards.nortelnetworks.com>; Sat, 25 Mar 2000 12:00:46 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 102702 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 25 Mar 2000 11:59:43 -0500 Received: from tsmceu.tsmc.nl by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.351D83A0@standards.nortelnetworks.com>; Sat, 25 Mar 2000 11:49:42 -0500 Received: from 193.78.210.10 by tsmceu.tsmc.nl (SMI-8.6/SMI-SVR4) id RAA06816; Sat, 25 Mar 2000 17:08:24 +0100 Message-ID: <200003251608.RAA06816@tsmceu.tsmc.nl> Date: Sat, 25 Mar 2000 09:01:58 EST Reply-To: greatnews1@TEXTO.SAPO.PT Sender: "Media Gateway Control (megaco)" From: greatnews1@TEXTO.SAPO.PT Subject: (()) Earn Extra Money Working at Home (()) X-To: Friend@public.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM ----------------------------------------------------------------------------------------------- I apologize if receiving this email has caused you any inconvenience!! Please hit your DELETE key now if it has. ----------------------------------------------------------------------------------------------- Hey Friends ! ! ! I just wanted to let you in on an extremely explosive income opportunity. This company has been around for 3 years now. All the bugs have been worked out and it is poised at the very beginning of a tremendous growth stage. If you have been looking for an honest, work from home business that has dynamite products and a desire to help the "little guy" succeed, you have found it!! The Company even gives away corporate enrollments to their distributors....FREE! Lots of other freebies too! (including your own FREE webpage!) "... I'm a single working mom and my last month's check was $522.43. I've been involved for 1-year and only get to spend maybe 3 or 4 hours per MONTH on my business, thanks...!!" ---Maria L. Heavy hitters are joining this International company. Those that know the industry recognize the superior opportunity that the Company is offering! You have just gotten lucky; you are in the right place at the right time! Folks, this is Real! Just reply back and I'll send you the website address where you can get all the info including the enrollment form!! Please DON'T MISS OUT ON THIS!! Reply to the address below: Be sure to type "TELL ME MORE" on the subject line "mailto: send4more@texto.sapo.pt" <--- Reply Here & Type "TELL ME MORE" UPDATE! We have just formed a group consisting of the Top Recruiters within the company. Everyone belonging to this elite group has vowed to promote and create tremendous spillover for everyone. All those that enroll because of this email will automatically go into this elite group within the organization. PLEASE REPLY BACK NOW! ! ! The timing is perfect! I challenge you to find a better opportunity anywhere! No empty promises, just solid support along with the dedication to help you succeed! I have personally been involved for over 2 years now and have absolutely no regrets - just a solid second income !! Reply to the address below.... Be sure to type "TELL ME MORE" on the subject line. "mailto: send4more@texto.sapo.pt" <-- Reply Here & type "TELL ME MORE !!" Still not sure...? Sounds too good to be true...?? If you have ever thought to yourself, "Why can't I be in the right place at the right time?" Well, I can honestly say, YOU ARE NOW!!! 1. You can start for less than $25 2. You don't need an office, a staff of people, complex machinery, or other costly items. 3. You can start your business from home, and you can run it from your kitchen table. 4. Better yet, you can run your business from any city, town, or village -- anywhere! "... we believe and are living proof that this is one of the only viable and honest home based business opportunities on or off the net..." ---- Tim & Marcella Cundy, Canada So now what? Live the rest of your life wondering what if? Too much risk? Are you simply too skeptical? I don't blame you. You should be! I've seen many of the programs you have seen. I was on exactly the same boat. But believe me, this program WILL WORK FOR YOU. Our patented revolutionary system will help to build your business for you. With only a minimal effort on your part, you will have the ability to earn a substantial income all from the comforts of your own home!!! So there's only one thing left to do, ACT NOW!!! Reply to the address below.... Be sure to type "TELL ME MORE" on the subject line. "mailto: send4more@texto.sapo.pt" <-- Click Here & type "TELL ME MORE !!" ------------------------------------------------------------------------------------------------------- IMPORTANT NOTE: This message comes from an e-mail distribution server, not a traditional mail server. Please do not press reply to answer this email, as your message will not be responded to. To request more info, follow the instructions in the above paragraphs. As a responsible internet marketer, the list you are being mailed from has been filtered against a global Remove list. To be added to our remove list send a message to: mailbox2@mail.pt with REMOVE in the subject line. Once again, we would also like to apologize if receiving this message has caused you any inconvenience. ------------------------------------------------------------------------------------------------------- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Mar 26 01:50:09 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08918 for ; Sun, 26 Mar 2000 01:50:08 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E293B2B0@standards.nortelnetworks.com>; 26 Mar 2000 1:44:54 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 103506 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 26 Mar 2000 01:42:57 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9C7C4710@standards.nortelnetworks.com>; 26 Mar 2000 1:42:57 -0500 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Sun, 26 Mar 2000 00:47:45 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Sun, 26 Mar 2000 00:47:23 -0600 X-Mailer: Internet Mail Service (5.5.2650.21) Message-ID: Date: Sun, 26 Mar 2000 00:47:22 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Agenda For Melbourne To: MEGACO@STANDARDS.NORTELNETWORKS.COM My E-mail connectivity hasn't been what I hoped -- I don't even know if this message will get off. I can only be sure of being able to connect when I get to Adelaide Sunday afternoon. As a result, I didn't manage to do up an agenda by the official deadline. This is a first cut, with a final one to be set Sunday after I have feedback from you. Meeting Thursday morning 9:00-11:30 09:00-09:05 Agenda bashing 09:05-10:15 Base protocol open items Objective: close on required changes to draft-ietf-megaco-protocol-07.txt (subject to Study Group 16 concurrence) 10:15-11:15 Other work items Objective: identify open issues (if any) and whether Last Call should be issued 11:15-11:30 WG recharter/wrapup? I will issue a summary of base protocol status by Sunday evening, reflecting the Last Call discussions. "Other work items" include the following: draft-ietf-megaco-ipphone-02.txt Something on ATM, I assume. draft-ietf-megaco-naspkg-00.txt draft-bouwen-megaco-isdn-00.txt draft-brown-supplpkgs-00.txt draft-ietf-megaco-R2package-00.txt (needs refreshing!) draft-ietf-megaco-mib-00.txt (if no progress, we won't discuss) Let me know what else should be here or alternative suggestions for the agenda. All drafts can be found at http://www.ietf.org/internet-drafts/ Tom Taylor Advisor -- Emerging Carrier IP Standards E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Mar 26 09:55:32 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05097 for ; Sun, 26 Mar 2000 09:55:32 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B35ECBD0@standards.nortelnetworks.com>; 26 Mar 2000 9:50:21 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 103817 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 26 Mar 2000 09:48:29 -0500 Received: from mail.iagu.net (203.32.153.69) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6FD955B0@standards.nortelnetworks.com>; 26 Mar 2000 9:48:28 -0500 Received: from dhcp-32-247.ietf.connect.com.au [169.208.32.247] by mail.iagu.net (8.8.5/AndrewR-19990125) with ESMTP id AAA29906 return ; Mon, 27 Mar 2000 00:23:04 +0930 (CST) X-Mailer: Mozilla 4.51 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38DE8D56.D4C0AD2F@italtel.it> Date: Mon, 27 Mar 2000 00:21:10 +0200 Reply-To: Giuseppe Ricagni Sender: "Media Gateway Control (megaco)" From: Giuseppe Ricagni Subject: draft-ricagni-megaco-umts-all-ip-00.txt X-To: MobileIP X-cc: Antonella Napolitano To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Dear all, we would like to draw your attention a new I-D: the draft is a very preliminary work on the analysis and comparison of the diferent call control protocols foreseen by 3GPP in its "all-IP" scenario. As we didn't make it for the submission deadline, the I-D is temporarily available at http://195.103.28.224/ricagni/draft-ricagni-megaco-umts-all-ip-00.txt http://195.103.28.224/ricagni/draft-ricagni-megaco-umts-all-ip-00.ps for the postscipt version http://195.103.28.224/ricagni/draft-ricagni-megaco-umts-all-ip-00.pdf for the .pdf version The choice of the call control protocol is currently a very hot issue in 3GPP, and we would like to try to support this decision process "in the IETF way", to say, with open documents and technically-driven discussions. In this first version of the document, Megaco/H.248 is briefly analysed and a few scenarios are described (Registration, UMTS Mobile-to-UMTS Mobile call, UMTS Mobile-to-PSTN call). Please let us know any comments/remarks Thanking you in advance Best Regards Giuseppe Ricagni ---------------------------------------------------------- Giuseppe RICAGNI System Architecture and Product Planning Broadband Networks Italtel via Reiss Romoli - C10 20019 Castelletto di Settimo Milanese (MILANO) ITALY Phone: +390243888797 FAX: +390243888405 mailto:giuseppe.ricagni@italtel.it ---------------------------------------------------------- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Mar 26 20:15:34 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28116 for ; Sun, 26 Mar 2000 20:15:34 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.15A49C60@standards.nortelnetworks.com>; 26 Mar 2000 20:08:43 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 104792 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 26 Mar 2000 20:07:14 -0500 Received: from mail1.sourcenet.org (209.70.98.243) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.7934F650@standards.nortelnetworks.com>; 26 Mar 2000 19:57:11 -0500 Received: from Jacksonville (host-209-214-98-23.sav.bellsouth.net [209.214.98.23]) by mail1.sourcenet.org with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HVF83S68; Sun, 26 Mar 2000 20:02:43 -0500 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Sun, 26 Mar 2000 20:07:14 -0500 Reply-To: jeffallen@SOURCENET.ORG Sender: "Media Gateway Control (megaco)" From: jeffallen@SOURCENET.ORG Subject: ACN- More Info 1 RUID# 0392753 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Here is the information you requested. If I could save you 30% on your long distance each month would you be interested in giving it a try? Or at least receiving more information? It doesn't cost you anything to take advantage of the service's ACN is offering. ACN is a cooperative marketing company capitalizing on the world-wide deregulation of the utilities industries (Telecommunications / Internet / Gas and Electricity). ACN's services are attractively priced: FREE* paging service, FREE* unlimited Internet service, Long Distance as low as 5-cents a minute with ONE second billing (no rounding to the nearest minute) with a FREE 800 number! Try the long distance service 5 cents per minute 24/7 and pay no switching fees and if you decide after a month or two that you want to go back we'll switch you back for free. With the free 800#, give it out to your kids and other family members. When they call you it won't cost them anything and will only cost you 10 cents per minute. The company I am with is saving 50% on their long distance because our rates are half of what they were with the other carrier. This long distance works well with both businesses as well as residences. Our company signed up as a rep so that we could offer this as a service to all our customers and suppliers, and we get up to 8% each and every month based on the amount of their usage. ACN is a cooperative marketing company capitalizing on the world-wide deregulation of the utilities industries(Telecommunications / Internet / Gas and Electricity). It provides a solid opportunity to earn a lifelong, continuous RESIDUAL income every time someone makes a local or long-distance phone call, uses a pager, uses the internet, orders a product from the internet, or turns on their lights or air conditioning. Our representatives are simply helping people save money on basic services that they need every month, as well as helping other people make extra money by helping expand our business. The company is a proven entity: cash rich, debt free, with over $100 million in annual revenue in 1998, and with billings projected to be around $1 billion in 2000. Its just under seven years old with over 100,000 active independent representatives throughout the USA, Canada and Europe. Over 75 people have achieved the company's top position of Regional Vice President with average RESIDUAL income of $33,000 per month. Some earn over $100,000 per month. But more important, there are a lot of "average" people making a "more-than-average" extra income. ACN has been featured in Success magazine and was listed as the 22nd fastest growing company in Inc. magazine’s list of the 500 top privately held companies in America. The growth in the next 2 years will be tremendous: The telecom Industry will be the world’s first Trillion-dollar industry by the end of the year. Our market share is currently less than 1 percent. With only a small increase in market share, we’ll grow tremendously because the industry is growing so rapidly. The same growth is expected for ACN's Internet business. The deregulation that took place in the Telecommunications Industry in the USA over the past 15 years is now taking place in Canada and Europe where we are positioning our business in all of the western European markets. ACN is currently established in the UK, Germany, Holland, Denmark, Finland, and Sweden and is getting itself established in Switzerland, Austria, France, Italy, Spain and the benelux countries within the upcoming months. European entrepreneurs have received ACN with enthusiasm, because the ACN cooperative marketing business model taking advantage of the deregulation of telecommunications has already been tested and proven in the USA. Plus, ACN provides savvy business people the opportunity to immediately position themselves in the multi-billion European telecommunications industry as the big government monopolies are being deregulated, all without any major capital investments simply by utilizing the talents of average people seeking an opportunity to make some extra income for themselves. Deregulation of gas & electric utilities is taking place throughout the USA. ACN Energy is currently marketing gas and/or electricity in 43 public utility service areas in New York, New Jersey, Pennsylvania, Ohio, Virginia, Maryland, Washington DC, Georgia, and California. In the past year ACN Energy has become the #1 alternate energy provider for residential service in the state of California and #4 in the nation. ACN Energy is currently being registered with additional Public utility commissions and is positioning as an alternate energy provider in all 50 states as they deregulate. In just the past year, we have acquired over 125,000 gas and electric customers for ACN Energy. ACN will be "bundling" services if the near future, whereby our customers will be given the opportunity to get their long distance, local calling, gas, electricity, Internet, paging, and possibly even wireless or cable TV services all from one source on one bill. The advantage to our customers being that the more services they choose to include in the bundle, the greater discount they receive. Establishing a large representative organization and resultant customer base now, will position you for tremendous increases in residual income when the company markets directly to your customer base by stuffing their bills with notices of new services and greater discounts whenever these new services become available in their area. Basically the company will be doing the work of getting existing customers to try new services, but the ACN representatives will get he commissions, month after month for as long as they're a customer. Studies have shown that for each service included in a bundle, the customer retention increases by as much as 50 percent. ACN is different in many respects from traditional direct marketing companies. ACN is simply a "customer acquisition" machine, with a win-win-win situation for all. The utility providers get customers with no up-front advertising costs; the customer gets a discount on quality services they have to buy anyway; and we get on-going commissions over and over as long as they remain a customer. Sell it once, and get paid forever. The attraction is threefold: 1) There are no monthly requirements to purchase or sell "products". There is no inventory…..we’re simply in the business of acquiring customers for services that everyone needs and must get every month. 2) No money changes hands when a service is sold…we’re merely giving away discounts on services people already use. They still get their bill from their utility provider. We sell the customer once…and they are on it month after month, year after year. 3) There is a unique opportunity to be awarded stock options because the company is sharing twenty-five percent of its stock over the next 10 years to those representatives who lead the expansion of the business and achieve the position of Regional Vice President (RVP). With the proper work ethic, you too could earn the right to be in the pool of representative who will share in these bonuses. (FYI, $5 million in pre-IPO stock options were awarded to the top 52 representative for 1998......which should be worth about $50 million in the next year after the company goes public) I have owned my own company for the past 15 years, I started in this type of business part time as an exit strategy from the problems with traditional business. I was able to make the transition to full time in just under a year. Now I work out of my home and am available to the family since I am now in full control of my time. We were recruited as part of a team by the founders of ACN to help them in their expansion programs in the USA, Canada and in Europe because of our successful track record in this industry. My sponsors are top producing Regional Vice Presidents Ron and Jan Malezis, who have 15 years experience in the industry and they are sponsored directly by the company. They are two of the nicest and most supportive people you would ever want to meet. Ron was a mortgage broker before he ventured into network marketing and he achieved the top position of RVP with ACN in a record-breaking seven months. Jan was a nurse before getting involved in network marketing and was just recently promoted to ACN's top position of RVP independent of her husband. She has consistently been in the top-10 producers within ACN. Ron and Jan get paid residuals on a customer base of over 150,000 customers and they developed this over the past three years all from their home in the small town of Elizabethton, Tennessee. We also have a massive advertising and lead generation program, as well as an extensive array of recruiting and training tools via telephone, fax, websites, email, audio tape, video tape. All the infrastructure is in place and works. Our Reps just need to use it. Do your homework…and determine: 1) does it make business sense? 2) can you master the business? and..... 3) is it a duplicable process such that anybody can do it? Find out more by calling our recorded Info-line Holland 020-346-3881 Both English and Dutch UK 0171-744-0096 You can also learn about ACN at the corporate web site @ www.acninc.com just click on your countries flag. You can see a complete "Briefing" and even a "Quick Start" training as well as read all the info on the company in your language. You can view our opportunity video by going to our group support website www.acngfg.com. Information about ACN Energy can be found at website www.acnenergy.com For a third-party independent review of the ACN business opportunity, go to website: www.mlmreview.com/mlmreview/ACN003.html ###24-hour recorded Information at (212) 322-6225.####### I'm also inviting you to listen in to our LIVE 20-minute EUROPEAN CONFERENCE CALL Tuesdays and Thursdays 001-580-431-8050 pin 2261# 19:30 UK 20:30 Holland, Sweden, Germany, Denmark 21:30 Finland Wednessdays 001-423-362-4150 pin 9414# 19:15pm UK, 20:15pm Holland, Germany, Sweden, Denmark 21:15pm Finland Just call this number at the above time and punch in the pin when prompted. The call will start shortly therafter and will explain the opportunity, compensation plan, and company information. You will here people from all over Europe, Canada, and the USA on the call. Please be on the call on time. If you're looking for a fun new challenge with a tremendous upside potential with true time leveraged residual income where you can leverage your European connections , but without the inherent risk associated with startup companies, and without giving up what your already doing, give this careful consideration. Please call me after you've reviewed this preliminary information and I'll send you a separate email with an overview of the compensation plan which we can discuss over the phone. Remember to ask me about the special bonuses that make it possible for the average person to earn an extra $2,000 to $3,000 in the next months. Sincerely, Jeff Solochek RUID# 0392753 912-826-1311 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Mar 27 00:45:11 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18007 for ; Mon, 27 Mar 2000 00:45:10 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E1A5A5F0@standards.nortelnetworks.com>; Mon, 27 Mar 2000 0:39:16 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 105210 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 27 Mar 2000 00:37:22 -0500 Received: from smtprtp1.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9D7BD980@standards.nortelnetworks.com>; Mon, 27 Mar 2000 0:37:22 -0500 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp1.ntcom.nortel.net; Mon, 27 Mar 2000 00:40:56 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Mar 2000 00:40:53 -0500 X-Mailer: Internet Mail Service (5.5.2650.21) Message-ID: Date: Mon, 27 Mar 2000 00:40:50 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: FW: new proposed TIPHON work items To: MEGACO@STANDARDS.NORTELNETWORKS.COM Megaco followers may have an interest in this one, considering the recent discussions on interoperability testing. Is this a valid work item, is it premature, is it a necessary step? Comments? > -----Original Message----- > From: Schink Helmut [SMTP:Helmut.Schink@icn.siemens.de] > Sent: Thursday, March 23, 2000 7:40 AM > To: new-work@ietf.org > Cc: 'TIPHON_PMC' > Subject: new proposed TIPHON work items > > A series of new work items have been proposed at the TIPHON#17 meeting: > TIPHON has not made any determination as yet. The following titles have > submitted: > [[TomT]] ... > 11.Protocol Implementation Conformance Statement (PICS) proforma for the > support of physically decomposed multimedia gateway; Support of ITU-T > recommendation H.248 > > more details can be found at: <> > > Best regards > > Helmut Schink > > -------------------------------------------------------------------------- > -- > ------------ > Dr. Helmut Schink > Siemens AG > Information and Communication Networks > Advanced Network Standards > phone: +49 89 722 44523 > mobile: +49 172 8146471 > mailto:helmut.schink@icn.siemens.de > http://intranet.icn.siemens.de/marketing/cs21/index.html (intranet use > only) > http://www.siemens.de (publically accessible) > <> begin 600 new_WIs_for_approval.htm M/"$M+2!396QE8W0@1$E35$E.0U0@4%)/5$]465!%+E-405154U]#3T1%,2P@ M4%)/5$]465!%+E-405154U]#3T1%,BP@1$530U))4%0@1E)/32!04D]43U19 M4$4@24Y.15(@2D])3B!404)?34E,15-43TY%7T-/1$4@3TX@4%)/5$]465!% M+DU,4U]#3T1%(#T@5$%"7TU)3$535$].15]#3T1%+DU,4U]#3T1%(%=(15)% M(%!23U1/5%E012Y35$%455-?0T]$13$],"!!3D0@4%)/5$]465!%+E-40515 M4U]#3T1%,B`@25,@3E5,3"`M+3X-"CPA+2T@4V5L96-T($1)4U1)3D-4(%!2 M3U1/5%E012Y35$%455-?0T]$13$L(%!23U1/5%E012Y35$%455-?0T]$13(L M($1%4T-225!4($923TT@4%)/5$]465!%($E.3D52($I/24X@5$%"7TU)3$53 M5$].15]#3T1%($].(%!23U1/5%E012Y-3%-?0T]$12`](%1!0E]-24Q%4U1/ M3D5?0T]$12Y-3%-?0T]$12!72$5212!04D]43U194$4N4U1!5%537T-/1$4Q M/3`@04Y$(%!23U1/5%E012Y35$%455-?0T]$13(@($E3($Y53$P@+2T^#0H\ M:'1M;#X-"@T*/&AE860^#0H\;65T82!.04U%/2)$15-#4DE05$E/3B(-"D-/ M3E1%3E0](E1H92!%5%-)(%=O'0O:'1M;#L@8VAA7!E.B`\+V9O;G0^/&9O;G0-"B`@("!325I%/2(R M(B!&04-%/2)!3H@/"]F;VYT M/CQF;VYT(%-)6D4](C(B#0H@("`@1D%#13TB07)I86PB($-/3$]2/2(C-#0V M,CA%(CX\80T*("`@(&AR968](FAT='`Z+R]W=W'!E'0@4W1A='5S.CQB3TQ M,"9A;7`[<5-/4E0]4D5&3D(F86UP.W%40E])1#TR.3$E,T)425!(3TXF86UP M.W%)3D-,541%7U-50E]40CU43TQ,"9A;7`[<5-/4E0]4D5&3D(F86UP.W%40E])1#TR.3$E,T)425!(3TXF M86UP.W%)3D-,541%7U-50E]40CU43TQ,"9Q4T]25#U2149.0B9Q5$)?240],CDQ)3-"5$E0 M2$].)G%)3D-,541%7U-50E]40CU43TQ,"9A;7`[<5-/4E0]4D5&3D(F86UP.W%4 M0E])1#TR.3$E,T)425!(3TXF86UP.W%)3D-,541%7U-50E]40CU4'!E3TQ,"9A;7`[<5-/4E0]4D5&3D(F86UP.W%40E])1#TR M.3$E,T)425!(3TXF86UP.W%)3D-,541%7U-50E]40CU4'!E M'0@4W1A='5S.CQB7!E.B`\+V9O;G0^/&9O;G0-"B`@("!325I%/2(R(B!&04-%/2)! M3H@/"]F;VYT/CQF;VYT(%-) M6D4](C(B#0H@("`@1D%#13TB07)I86PB($-/3$]2/2(C-#0V,CA%(CX\80T* M("`@(&AR968](FAT='`Z+R]W=W'!E7!E.B`\+V9O;G0^/&9O;G0-"B`@("!325I%/2(R(B!&04-%/2)!3H@/"]F;VYT/CQF;VYT(%-)6D4] M(C(B#0H@("`@1D%#13TB07)I86PB($-/3$]2/2(C-#0V,CA%(CX\80T*("`@ M(&AR968](FAT='`Z+R]W=W'!E3TQ,"9A;7`[<5-/4E0]4D5&3D(F86UP.W%40E])1#TR.3$E,T)425!(3TXF M86UP.W%)3D-,541%7U-50E]40CU4'!E3TQ,"9A;7`[<5-/4E0]4D5&3D(F86UP M.W%40E])1#TR.3$E,T)425!(3TXF86UP.W%)3D-,541%7U-50E]40CU4'!E3TQ,"9Q4T]25#U2149.0B9Q5$)? M240],CDQ)3-"5$E02$].)G%)3D-,541%7U-50E]40CU47-T96US(#QBF4] M(C(B/CQA#0H@("`@:')E9CTB:'1T<#HO+W=E8F%P<"YE='-I+F]R9R]W;W)K M<')O9W)A;2]297!O3TQ,R9A;7`[<5-/4E0]4D5&3D(F86UP.W%40E])1#TR.3$E,T)425!(3TXF M86UP.W%)3D-,541%7U-50E]40CU4F4](C(B/E9EF4](C(B/E)E9BX@/"]F;VYT/CQF;VYT(&-O;&]R/2(C-#0V,CAE(B!F86-E M/2)!'!E3TQ M,R9Q4T]25#U2149.0B9Q5$)?240],CDQ)3-"5$E02$].)G%)3D-,541%7U-5 M0E]40CU4F4](C(B/CQB/D5N9"!T;R!%;F0@ M475A;&ET>2!O9@T*("`@(%-E7!E.B`\+V9O;G0^/&9O;G0-"B`@("!C;VQO MF4](C(B/CQB/E13/"]B/B`\ M+V9O;G0^/&)R/@T*("`@(#QF;VYT(&-O;&]R/2(C,#`P,#`P(B!F86-E/2)! MF4](C(B/CPA+2T\02!(4D5&/2)H M='1P.B\O=V5B87!P+F5T'!E'!E3TQ,R9Q4T]25#U2149.0B9Q5$)?240],CDQ)3-"5$E02$].)G%) M3D-,541%7U-50E]40CU4F4](C(B/D-U M'0@4W1A='5S.CQB7!E.B`\ M+V9O;G0^/&9O;G0-"B`@("!C;VQOF4](C(B/CQB/E13/"]B/B`\+V9O;G0^/&)R/@T*("`@(#QF;VYT(&-O M;&]R/2(C,#`P,#`P(B!F86-E/2)!F4](C(B/CPA+2T\02!(4D5&/2)H='1P.B\O=V5B87!P+F5T'!E'!E3TQ,R9Q4T]25#U2149.0B9Q M5$)?240],CDQ)3-"5$E02$].)G%)3D-,541%7U-50E]40CU4F4](C(B/CQB/E!R;W1O8V]L($EM<&QE;65N=&%T:6]N#0H@ M("`@0V]N9F]R;6%N8V4@4W1A=&5M96YT("A024-3*2!P2!D96-O;7!O; Mon, 27 Mar 2000 09:47:30 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B50468A0@standards.nortelnetworks.com>; Mon, 27 Mar 2000 9:42:03 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 105761 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 27 Mar 2000 09:40:20 -0500 Received: from alemail1.firewall.lucent.com (192.11.221.161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.774A1A00@standards.nortelnetworks.com>; Mon, 27 Mar 2000 9:40:20 -0500 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 JAA05256 for ; Mon, 27 Mar 2000 09:45:04 -0500 (EST) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA05014 for ; Mon, 27 Mar 2000 09:44:48 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA08176; Mon, 27 Mar 2000 16:44:43 +0200 (MET DST) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA08172; Mon, 27 Mar 2000 16:44:42 +0200 (MET DST) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <38D98F8F.35A2C799@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38DF73C7.D2D33E39@lucent.com> Date: Mon, 27 Mar 2000 16:44:23 +0200 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: V16 review - Editorial comments To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Some more comments. Please see below. John Christian Groves wrote: > > G'Day Nancy, > > Please see my comments marked [CHG]. > > Cheers, Christian > > Nancy-M Greene wrote: > > > > Brian, John, > > I believe each of the following is an editorial change to V16. You > > have both seen most of these already, and commented on them - I am > > posting them to the megaco list this time, with the proposed > > resolutions. Please comment! > > > > 1- Section 7.1.1 Specifying Parameters > > Issue: para. starting with "Unspecified mandatory parameters > > (i.e. mandatory parameters not specified in a descriptor) result > > in the command responder retaining the previous value for that > > parameter." > > > > Comment: It seems that this section applies only to mandatory fields > > in > > Local and Remote descriptors (see section 7.1.8). For example, when > > a mandatory parameter is unspecified in the Local descriptor, > > then it retains the value it already has. But, a mandatory parameter > > in a ServiceChange HAS to be there I would think. For example, the > > ServiceChangeMethod descriptor is mandatory, and must > > always be present. > > > > Proposal: Preface the quoted sentence in 7.1.1 with "For Local and > > Remote Descriptors, unspecified mandatory parameters (i.e. mandatory > > parameters not specified in a descriptor) result in the ...." I'm not sure that local and remote are the exceptions, or ServiceChange. Maybe we could say that if there is a previous value, it is retained. If there is not, then you generate an error message. > > > > 2- Section 7.1.6 Stream Descriptor > > Issue: last sentence of first para, "A stream is deleted by > > setting empty Local and Remote descriptors for the stream with > > ReserveGroup and ReserveValue in LocalControl set to "false" on > > all terminations in the context that previously supported that > > stream." > > > > Comment: We don't have false or true in the ABNF, only "ON/OFF". The > > text uses both true/false, and on/off. > > > > Proposal: Make no changes to the text. Just add this comment: > > "ON = true, and OFF = false" to the ABNF. > [CHG] OK > > > > > 3- Section 7.1.7 LocalControl Descriptor - ReserveGroup/ReserveValue > > Issue: There is no explanation as to what ReserveValue and > > ReserveGroup mean. > > > > Proposal: Add text something like the following: > > "In order to state that one session description is to be selected > > out of a list, ReserveGroup is set to "false". If resources for all > > session descriptions are to be reserved, ReserveGroup is set > > to "true". In order to state that a parameter with a list of values, > > e.g. multiple rtp payload types, requires one value is to be > > selected from the list, ReserveValue is set to "false". If resources > > for all values are to be reserved, ReserveValue is set to "true". > > In other words, overspecifying by giving a list of values can happen > > independently at the session description level and at the parameter > > level. " > [CHG] I don't think this is necessary. The text currently states: "The > boolean-valued Reserve properties, ReserveValue and ReserveGroup" and > then it follows in the next 2 paragraphs about what to do. The terms > value and groups are used in other sections. This isn't an error at best > its something for a possible implementors guide. I agree with Christian that we don't need the extra text. > > 4- Section 7.1.9 Events Descriptor - eventDM > > Issue: eventDM is not mentioned in this section while it is part of > > the > > eventsDescriptor syntax. > > > > Proposal: Add this sentence: > > "If a digit map is required in the EventsDescriptor, EventDM is used > > to carry either the name or the value of the digit map. See > > section 7.1.14." Agreed, eventDM definitely has to be mentioned in this section, with a reference to 7.1.14. > > 5- Section 7.1.11 Signals Descriptor > > Issue: setting of the signal list type > > > > Proposal: Add the following to section 7.1.11: > > * on/off in signal list > > -> it must be the last element, and signal list type must be > > on/off > > * timeout in signal list (and NO on/off signals in the list) > > -> signal list type must be timeout > > * only brief signals in signal list > > -> signal list type defaults to brief. > > [CHG] Isn't this in the determined draft? 2nd paragraph after list. Yes, it is there. > > 6- Section 7.1.12 Audit Descriptor, and also auditItem in the ABNF > > Issue: the last entry in the table is "EventBuffer". auditItem in the > > ABNF > > does not qualify it either which is incorrect. > > > > Proposal: Change "EventBuffer" to "EventBuffer Descriptor" in both > > section 7.1.12 > > and in the ABNF. Hmm. That would make EventBufferDescriptor the only entry in the table that includes the word "descriptor". Since the text above the table already says that "[the] AuditDescriptor specifies the list of descriptors to be returned", I don't think that the proposed change adds anything anyway. > > 7- Section 7.1.13 ServiceChangeDescriptor > > Issue: Extension is not part of the enumeration > > > > Comment: Is ServiceChangeDescriptor supposed to be extendable or not? > > The ABNF still has an extension parameter in it. > [CHG] I don't like the extension parameter but we do have it. See 7.2.8 > no.7 in the list. And the text in 7.2.8 "The optional Extension > parameter may contain any value whose meaning is mutually understood by > the MG and MGC." The extension parameter in 7.2.8 is not the one that Nancy & Abdallah mean. The one in 7.2.8 is for ServiceChangeMethod. The extension Nancy and Abdallah refer to is adding a new parameter to the ServiceChangeDescriptor itself (ServiceChangeSeason, ServiceChangeTax, ...). I don't think that we need the extension at that level. > > 8- Section 7.1.18 Topology Descriptor > > Issue: para starting with "(T1,T2, bothway) means that .... > > loopbacks are created by setting the TerminationMode." > > > > Comment: We don't have TerminationMode any more. > > > > Proposal: change it to read: > > "...loopbacks are created by setting the StreamMode property to > > LoopBack > > in the LocalControlDescriptor." > [CHG] Perhaps we can just delete the text after the ";"? StreamMode = > Loopback is in 7.1.7 Good idea, just end the sentence with "[...] no loopback is introduced." > > 9- 7.2.5 Audit Value > > Issue "W-" and "O-" > > Comment: Text does not describe that wildcarded response > > is qualified by "W-". Also, no text explaining that > > optional commands are qualified by "O-". > > > > Proposal: in section 7.2.5, add the following: > > "The wildcard response option (see section 6.2.2) is particularly > > useful > > to limit the size of a n audit value command which uses a wildcard > > terminationId. In ASN.1 encoding (Annex A), the flag "wildcardReturn" > > is set on a command, and in ABNF (Annex B), the command is qualified > > by the "W-" option." > > [CHG] Sect 6.2.2 already covers much of this. I don't see a need to > repeat the information in 7.2.5. 6.2.2 even recommends that this is > useful for audit. I agree with Christian that we don't need to restate the purpose of the mechanisms. We do need to tie wildcard response to W-, and optional commands to O-. I don't think that the link to W- should be added in 7.2.5. Annex B (and maybe 6.2.2) seems to be a better place. The link with the ASN.1 wildcardReturn and optional is clear enough, I believe. > > Also, in section 8, add the following: > > "In ASN.1 encoding, the flag "optional" is set on a command, and in > > the > > ABNF, the command is qualified with the "O-" option." > > > > 10- Section 7.2.6 AuditCapabilities > > Issue: AuditCapability API > > > > Comment: same as in 9-Section 7.2.5 > > > > Proposal: Add same sentences as above, to this section. > > > [CHG] See my comment on 7.2.5 I don't think we need a change here. > > 11- Section 7.2.6 AuditCapabilities - DigitMap and Packages > > Issue: DigitMap and Packages in the ABNF > > > > Comment: The ABNF allows DigitMap and Packages > > in the return of AuditCapability. The text says no. Need to > > add a comment in the ABNF that explains this. > > > > Proposal: Add the following comment to the ABNF: > > "DigitMap and Packages are not permitted to be part of > > AuditCapabilities" People would hopefully read the text when implementing the protocol, not just the syntax. But I suppose that it doesn't hurt to add the comment. > > 12- ANNEX B: signalListParm > > Issue: signalListParm = signalRequest > > > > Comment: This is redundant. > > > > Proposal: in the ABNF, signalRequest should replace > > signalListParm in signalList. I'm trying to keep changes limited to bug fixing. Does this change fix anything that is broken? > > 13- ANNEX B:digitMapValue > > Issue: digitMapDescriptor = DigitMapToken EQUAL digitMapName > > ( LBRKT digitMapValue RBRKT ) > > > > Comment: error with the round brackets > > > > Proposal: it should be > > digitMapDescriptor = DigitMapToken EQUAL digitMapName > > [ LBRKT digitMapValue RBRKT ] Ok. > > 14- ANNEX B: version token > > Issue: VersionToken is missing in the ABNF. > > > > Proposal: Add VersionToken = ("Version" / "V") Ok. > > Nancy & Abdallah > > > > -------------------------------------------------------------------------- > > > > Nancy M. Greene > > Internet & Service Provider Networks, Nortel Networks > > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Mar 27 10:08:46 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14613 for ; Mon, 27 Mar 2000 10:08:45 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A5D55B20@standards.nortelnetworks.com>; Mon, 27 Mar 2000 10:03:06 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 105796 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 27 Mar 2000 10:01:13 -0500 Received: from auemlsrv.firewall.lucent.com (192.11.223.161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6241B430@standards.nortelnetworks.com>; Mon, 27 Mar 2000 10:01:13 -0500 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 KAA04836 for ; Mon, 27 Mar 2000 10:06:01 -0500 (EST) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA04798 for ; Mon, 27 Mar 2000 10:06:00 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA10932; Mon, 27 Mar 2000 17:05:59 +0200 (MET DST) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id RAA10925; Mon, 27 Mar 2000 17:05:58 +0200 (MET DST) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <4.3.1.2.20000324102207.00c2c610@dogwood.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38DF78C4.A5591F18@lucent.com> Date: Mon, 27 Mar 2000 17:05:40 +0200 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: V16 review - events Descriptor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit All, I agree that we have to add text indicating that the MG waits for a new EventsDescriptor in step 2a of case 1. The proposed addition to case 2 is indeed redundant. I don't really care whether we add the proposed text. John Chip Sharp wrote: > > At 02:29 PM 3/23/00 -0600, Nancy-M Greene wrote: > > >This comment is editorial, trying to improve the clarity of section 7.1.9: > > > >(and, it is, I hope, our last comment on v16 :-) ) > > > >Section 7.1.9 Events Descriptor > >Issue: Case 1, item 2a), and Case 2 are not yet completely clear. > >Case 1, item 2a) currently says: > >"... detected. The MG then waits for a new EventsDescriptor. While waiting > >for a new EventsDescriptor, any events matching the EventsBufferDescriptor > >will be placed in the EventBuffer and the event processing will repeat from > >step 1." > > > >Proposal: > >i) Change "While waiting..." sentence in Case 1, item 2a) to be: > >"While waiting for a new EventsDescriptor, any events detected which > >appear in the current EventsBufferDescriptor will be placed in the > >EventBuffer. > >When a new EventDescriptor is received, event processing repeats > >from step 1." > > Yes. The current text is clearly incorrect. If implemented exactly as it > currently says, I believe it would cause an infinite loop. The text above > reflects the original intent in TD-85 from Geneva. I also think this > should be in the errata for H.248 in June since it is an important > technical correction. > > BTW, the formatting of this section in draft-ietf-megaco-protocol-07.txt is > not correct. > > >ii) and add this sentence to Case 2: > >"Events detected that match an event in the new EventsDescriptor are > >immediately notified." > > I believe we had a statement like this originally, but it was removed since > it was redundant with the sentance at the beginning of the section: > "The MG shall send a Notify command to the MGC when it detects an event in > the Events Descriptor." > > The statement you suggest is a true statement. I tend to think redundant > encoding in this section would be helpful. :-) > > Again, the formatting of this section is incorrect. The current text in > version 7 implies that all the text following "Case 2" is part of Case 2 > when in fact it is only the sentence immediately following the words "Case > 2" plus the above if it is added. > > >Nancy > >Abdallah > > > >-------------------------------------------------------------------------- > >Nancy M. Greene > >Internet & Service Provider Networks, Nortel Networks > >T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > > http://www.netaid.org > ------------------------------------------------------------------------- > Chip Sharp CTO Consulting Engineering > Cisco Systems > Reality - Love it or Leave it. > ------------------------------------------------------------------------ -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Mar 27 12:14:36 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21790 for ; Mon, 27 Mar 2000 12:14:36 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.47D52840@standards.nortelnetworks.com>; Mon, 27 Mar 2000 12:09:19 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 105942 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 27 Mar 2000 12:07:34 -0500 Received: from rambo.globespan.net (209.191.59.250) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.08F32280@standards.nortelnetworks.com>; Mon, 27 Mar 2000 12:07:34 -0500 Received: from ficon-tech.com (200-38.buz.net [64.6.38.200]) by rambo.globespan.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HSWZV3PY; Mon, 27 Mar 2000 12:10:07 -0500 X-Mailer: Mozilla 4.06 [en] (WinNT; I) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38DF9548.F3D3A998@ficon-tech.com> Date: Mon, 27 Mar 2000 11:07:20 -0600 Reply-To: hsanand@ficon-tech.com Sender: "Media Gateway Control (megaco)" From: Harpreet Singh Anand Subject: v16 comments: Event Handling To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello all, The description for event handling in Sec 7.1.9 needs to be clarified for the following states: (a) Consider the state when Event Bfr Control (EBC) is LockStep and Mg is collecting events according to EventBuffer Descriptor (EBD). If in this state MG receives a command which sets EBC to Off (and the command does not contain any new ED), then what should MG do? Should the MG - flush event buffer queue and start collecting events according to the last ED that was set. OR - Flush event buffer and keep on collecting events according to EBD. (b) Consider the state when Event Bfr Control (EBC) is LockStep and Mg is collecting events according to EventBuffer Descriptor (EBD). If in this state MG receives a command which sets a new EBD, then what should MG do? Should the MG - flush the event bfr queue and start collecting events according to the new EBD OR - keep the events in the bfr q. which correspond to the EBD and remove other events and start collecting events according to the new EBD OR - does not flush the event q and start collecting events according to the new EBD (c) Consider the state when Event Bfr Control (EBC) is LockStep and Mg is collecting events according to Event Descriptor (ED). Also consider that at this time EBD is not specified. If in this state MG receives an event which matches an event in the ED. The MG would send the Notify command request. If EBD would have been specified then the MG would have started collecting events according to the EBD. But if the EBD is not specified, then what should MG do ? Should the MG - Remain in the same state and keep on collecting according to the current ED ? OR - Stop collecting events as EBD is not available. Regards, Harpreet From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Mar 27 15:41:50 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24571 for ; Mon, 27 Mar 2000 15:41:50 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3898D580@standards.nortelnetworks.com>; Mon, 27 Mar 2000 15:36:29 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 106064 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 27 Mar 2000 15:35:39 -0500 Received: from rambo.globespan.net (209.191.59.250) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1A996400@standards.nortelnetworks.com>; Mon, 27 Mar 2000 15:35:39 -0500 Received: from ficon-tech.com (64.6.38.200 [64.6.38.200]) by rambo.globespan.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HSWZVPSZ; Mon, 27 Mar 2000 15:38:08 -0500 X-Mailer: Mozilla 4.06 [en] (WinNT; I) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <38DFC606.93C0AFC9@ficon-tech.com> Date: Mon, 27 Mar 2000 14:35:18 -0600 Reply-To: hsanand@ficon-tech.com Sender: "Media Gateway Control (megaco)" From: Harpreet Singh Anand Subject: v16 comments: digit map To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hello all, 1. Sec 7.1.14, paragraph after numbered item 3, “The timers are configurable parameters to a DigitMap. The Start timer is started at the beginning of every digit map use, but can be overridden.”. What is the method for overriding start of “Start” timer ? Is it by configuration ? 2. Definition of digitMapRange in ABNF: digitMapRange = ("x" / LWSP "[" LWSP digitLetter LWSP "]" LWSP) digitLetter = *((DIGIT "-" DIGIT ) / digitMapLetter) (a) According to the current definition, the digitMapRange can be empty, that is, “[]” would be considered as a valid digitMapRange. I don't think [] would make any sense. The definition of digitLetter should be changed to “1*((DIGIT “-“ DIGIT) / digitMapLetter)” (b) Are the inter-event timers “L”, “S” and long duration modifier “Z” allowed in digitMapRange ? Regards, Harpreet From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Mar 27 15:47:50 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24597 for ; Mon, 27 Mar 2000 15:47:48 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1013A530@standards.nortelnetworks.com>; Mon, 27 Mar 2000 15:42:31 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 106081 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 27 Mar 2000 15:40:42 -0500 Received: from rambo.globespan.net (209.191.59.250) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.CF0D5FE0@standards.nortelnetworks.com>; Mon, 27 Mar 2000 15:40:42 -0500 Received: from ficon-tech.com (64.6.38.200 [64.6.38.200]) by rambo.globespan.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HSWZVPT7; Mon, 27 Mar 2000 15:43:17 -0500 X-Mailer: Mozilla 4.06 [en] (WinNT; I) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <38DFC73B.F8DE279F@ficon-tech.com> Date: Mon, 27 Mar 2000 14:40:27 -0600 Reply-To: hsanand@ficon-tech.com Sender: "Media Gateway Control (megaco)" From: Harpreet Singh Anand Subject: v16 comments: Editorial To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hello all, 1. Sec 6.2.4 (Descriptor Table): The description for DigitMap Descriptor says "Instructions for handling DTMF tones at the MG". This definition can be made more generic and independent of DTMF. 2. Sec 7.1.18: First bullet. It should read as “ (T1, T2, isolate) means that the Terminations matching T2 do not receive media from the Terminations matching T1, and vice versa” instead of " ..... nor vice versa." 3. Sec 7.1.18 First paragraph after the end of the table: it should read “A oneway connection must be established …”. (be is missing in the text) Regards, Harpreet From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 28 03:50:06 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18396 for ; Tue, 28 Mar 2000 03:50:05 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F3CB3EA0@standards.nortelnetworks.com>; Tue, 28 Mar 2000 3:44:42 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 106907 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Mar 2000 03:43:28 -0500 Received: from ihemlsrv.firewall.lucent.com (192.11.222.161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C76F5940@standards.nortelnetworks.com>; Tue, 28 Mar 2000 3:43:28 -0500 Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id DAA11646 for ; Tue, 28 Mar 2000 03:48:19 -0500 (EST) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id DAA11635 for ; Tue, 28 Mar 2000 03:48:18 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA20696; Tue, 28 Mar 2000 10:48:17 +0200 (MET DST) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id KAA20692; Tue, 28 Mar 2000 10:48:17 +0200 (MET DST) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <38DFC606.93C0AFC9@ficon-tech.com> Content-Type: text/plain; charset=iso-8859-1 Message-ID: <38E071BD.8FABF9D7@lucent.com> Date: Tue, 28 Mar 2000 10:47:57 +0200 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: v16 comments: digit map To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA18396 Harpreet, 1. The "T" timer is used to override the default start timer. 2. (a) an empty digit map does not seem to make much sense. (b) I don't think that a digitmap range should contain the Z modifier or long and short timers. We should fix the syntax to disallow this. John Harpreet Singh Anand wrote: > > Hello all, > > 1. Sec 7.1.14, paragraph after numbered item 3, > “The timers are configurable parameters to a DigitMap. The Start timer > is started at the beginning of every digit map use, but can be > overridden.”. > > What is the method for overriding start of “Start” timer ? Is it by > configuration ? > > 2. Definition of digitMapRange in ABNF: > > digitMapRange = ("x" / LWSP "[" LWSP digitLetter LWSP "]" LWSP) > digitLetter = *((DIGIT "-" DIGIT ) / digitMapLetter) > > (a) According to the current definition, the digitMapRange can be empty, > that is, “[]” would be considered as a valid digitMapRange. I don't > think [] would make any sense. The definition of digitLetter should be > changed to “1*((DIGIT “-“ DIGIT) / digitMapLetter)” > > (b) Are the inter-event timers “L”, “S” and long duration modifier “Z” > allowed in digitMapRange ? > > Regards, > Harpreet -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 28 04:40:50 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18916 for ; Tue, 28 Mar 2000 04:40:50 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F608A750@standards.nortelnetworks.com>; Tue, 28 Mar 2000 4:34:53 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 107031 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Mar 2000 04:33:06 -0500 Received: from smtprtp.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.B6A367D0@standards.nortelnetworks.com>; Tue, 28 Mar 2000 4:33:06 -0500 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp.ntcom.nortel.net; Tue, 28 Mar 2000 04:37:35 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Mar 2000 04:37:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF9899.3F5D3BDA" Message-ID: <29400B68197CD31188830000F8CD15D343BCEF@zcard00q.ca.nortel.com> Date: Tue, 28 Mar 2000 04:37:32 -0500 Reply-To: Peter Blatherwick Sender: "Media Gateway Control (megaco)" From: Peter Blatherwick Subject: Re: new proposed TIPHON work items X-To: Tom-PT Taylor 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_01BF9899.3F5D3BDA Content-Type: text/plain Tom, list: I would personally not want to see more than one interoperability focus, at least initially. It would add overhead and could lead to contentions and confusion on what is actually correct from the multiple bodies. I don't care much which one -- whatever seems to meet the needs best -- but lets pick one only. IF bodies such as TIPHON wish to have an interoperability conformance statement, test suite or whatever, it should be identical for all such bodies irrespective of what forum the actual interop testing occurs in. Publishing a conformance statement or test suite might be a valuable output of the WG, after initial interop testing, but we're not ready yet IMO. I would also would like to make sure that especially the very first interop events are pretty closed door. The last thing we need is a pile of marketing and press getting in the way of engineering. There seems to be general agreement on this at least from those I have spoken to here so far. My $0.02 (which the Ozzies in the crowd have pointed out is subject to round off here ;-) -- Peter > -----Original Message----- > From: Taylor, Tom-PT [CAR:B904:EXCH] > Sent: Monday, March 27, 2000 12:41 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: FW: new proposed TIPHON work items > > Megaco followers may have an interest in this one, considering the recent > discussions on interoperability testing. Is this a valid work item, is it > premature, is it a necessary step? Comments? > > > -----Original Message----- > > From: Schink Helmut [SMTP:Helmut.Schink@icn.siemens.de] > > Sent: Thursday, March 23, 2000 7:40 AM > > To: new-work@ietf.org > > Cc: 'TIPHON_PMC' > > Subject: new proposed TIPHON work items > > > > A series of new work items have been proposed at the TIPHON#17 meeting: > > TIPHON has not made any determination as yet. The following titles have > > submitted: > > > [[TomT]] ... > > 11.Protocol Implementation Conformance Statement (PICS) proforma for > the > > support of physically decomposed multimedia gateway; Support of ITU-T > > recommendation H.248 > > > > more details can be found at: <> > > > > Best regards > > > > Helmut Schink > > > > > -------------------------------------------------------------------------- > > -- > > ------------ > > Dr. Helmut Schink > > Siemens AG > > Information and Communication Networks > > Advanced Network Standards > > phone: +49 89 722 44523 > > mobile: +49 172 8146471 > > mailto:helmut.schink@icn.siemens.de > > http://intranet.icn.siemens.de/marketing/cs21/index.html (intranet use > > only) > > http://www.siemens.de (publically accessible) > > <> > << File: new_WIs_for_approval.htm >> ------_=_NextPart_001_01BF9899.3F5D3BDA Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: new proposed TIPHON work items

Tom, list: 

I would personally not want = to see more than one interoperability focus, at least initially.  = It would add overhead and could lead to contentions and confusion on = what is actually correct from the multiple bodies.  I don't care = much which one -- whatever seems to meet the needs best -- but lets pick one = only.  IF bodies such as TIPHON wish to have an interoperability = conformance statement, test suite or whatever, it should be identical = for all such bodies irrespective of what forum the actual interop = testing occurs in.  Publishing a conformance statement or test = suite might be a valuable output of the WG, after initial interop = testing, but we're not ready yet IMO. 

I would also would like to = make sure that especially the very first interop events are pretty = closed door.  The last thing we need is a pile of marketing and = press getting in the way of engineering.  There seems to be = general agreement on this at least from those I have spoken to here so = far. 

My $0.02 (which the Ozzies in = the crowd have pointed out is subject to round off here ;-)

-- Peter


    -----Original Message-----
    From:   Taylor, Tom-PT [CAR:B904:EXCH]
    Sent:   Monday, March 27, 2000 12:41 AM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = FW: new proposed TIPHON work = items

    Megaco followers may have an interest = in this one, considering the recent
    discussions on interoperability = testing.  Is this a valid work item, is it
    premature, is it a necessary = step?  Comments?

    > -----Original Message-----
    > From: Schink Helmut = [SMTP:Helmut.Schink@icn.siemens.de]
    > Sent: Thursday, March 23, 2000 = 7:40 AM
    > To:   = new-work@ietf.org
    > Cc:   = 'TIPHON_PMC'
    > = Subject:      new proposed TIPHON work = items
    >
    > A series of new work items have = been proposed at the TIPHON#17 meeting:
    > TIPHON has not made any = determination as yet. The following titles have
    > submitted:
    >
    [[TomT]]  ...
    >  11.Protocol Implementation = Conformance Statement (PICS) proforma for the
    > support of physically decomposed = multimedia gateway; Support of ITU-T
    > recommendation H.248
    >
    > more details can be found at: = <<new_WIs_for_approval.htm>>
    >
    > Best regards
    >
    > Helmut Schink
    >
    > = ------------------------------------------------------------------------= --
    > --
    > ------------
    > Dr. Helmut Schink
    > Siemens AG
    > Information and Communication = Networks
    > Advanced Network = Standards
    > phone: +49 89 722 44523
    > mobile: +49 172 8146471
    > mailto:helmut.schink@icn.si= emens.de
    > http://intranet.icn.siemens.de/marketing/cs21/index.ht= ml (intranet use
    > only)
    > http://www.siemens.de (publically accessible)
    >  = <<new_WIs_for_approval.htm>>
     << File: = new_WIs_for_approval.htm >>

------_=_NextPart_001_01BF9899.3F5D3BDA-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 28 04:40:51 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18924 for ; Tue, 28 Mar 2000 04:40:51 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F732A860@standards.nortelnetworks.com>; Tue, 28 Mar 2000 4:34:55 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 106996 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Mar 2000 04:34:38 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.87ADE140@standards.nortelnetworks.com>; Tue, 28 Mar 2000 4:24:38 -0500 Received: from cisco.com (oz-syd-dial1-23.cisco.com [144.254.157.24]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id BAA28458; Tue, 28 Mar 2000 01:29:25 -0800 (PST) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <38DF9548.F3D3A998@ficon-tech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38E00357.6E68F710@cisco.com> Date: Mon, 27 Mar 2000 16:56:56 -0800 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Subject: Re: v16 comments: Event Handling X-To: hsanand@ficon-tech.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit At the risk of oversimplifying here, I think this boils down to which of these parameters are mandatory and which are optional. It would be *really* nice if we could get a table or something containing all the parameters and indicating for each if it's mandatory or optional. -- Flemming Harpreet Singh Anand wrote: > Hello all, > > The description for event handling in Sec 7.1.9 needs to be clarified > for the following states: > > (a) Consider the state when Event Bfr Control (EBC) is LockStep and Mg > is collecting events according to EventBuffer Descriptor (EBD). If in > this state MG receives a command which sets EBC to Off (and the command > does not contain any new ED), then what should MG do? Should the MG > - flush event buffer queue and start collecting events according to > the last ED that was set. OR > - Flush event buffer and keep on collecting events according to EBD. > > (b) Consider the state when Event Bfr Control (EBC) is LockStep and Mg > is collecting events according to EventBuffer Descriptor (EBD). If in > this state MG receives a command which sets a new EBD, then what should > MG do? Should the MG > > - flush the event bfr queue and start collecting events according to > the new EBD OR > - keep the events in the bfr q. which correspond to the EBD and > remove other events and start collecting events according to the new EBD > OR > - does not flush the event q and start collecting events according > to the new EBD > > (c) Consider the state when Event Bfr Control (EBC) is LockStep and Mg > is collecting events according to Event Descriptor (ED). Also consider > that at this time EBD is not specified. If in this state MG receives an > event which matches an event in the ED. The MG would send the Notify > command request. If EBD would have been specified then the MG would have > started collecting events according to the EBD. But if the EBD is not > specified, then what should MG do ? Should the MG > > - Remain in the same state and keep on collecting according to the > current ED ? OR > - Stop collecting events as EBD is not available. > > Regards, > Harpreet -- Flemming Andreasen Phone: +1 732 452 1667 Cisco Systems Fax: +1 240 359 5839 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 28 04:44:47 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18957 for ; Tue, 28 Mar 2000 04:44:46 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3FE33570@standards.nortelnetworks.com>; Tue, 28 Mar 2000 4:36:57 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 107062 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Mar 2000 04:35:41 -0500 Received: from smtprtp1.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1291CC80@standards.nortelnetworks.com>; Tue, 28 Mar 2000 4:35:41 -0500 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp1.ntcom.nortel.net; Tue, 28 Mar 2000 04:36:04 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Mar 2000 04:36:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF9899.072FD33A" Message-ID: <29400B68197CD31188830000F8CD15D343BCEE@zcard00q.ca.nortel.com> Date: Tue, 28 Mar 2000 04:35:57 -0500 Reply-To: Peter Blatherwick Sender: "Media Gateway Control (megaco)" From: Peter Blatherwick Subject: Re: Agenda For Melbourne X-To: Tom-PT Taylor X-cc: Bilalis Zacharias , Michael Brown 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_01BF9899.072FD33A Content-Type: text/plain Tom, list: As we discussed in the hall here yesterday, Zach, Mike and I have put together a quick overview of status and content overview of the package definitions that exist so far, including the ones you list below and all ITU defined packages. Hopefully we did not miss any -- its a bit confusing. Should not need more than 5-10 minutes to present. We think its useful to go over these as a lead in to some quick discussion on how to handle these in IETF documentation (if/when/how these move to RFC or whatever). Hopefully this helps. There is also seems to be a need for some discussion of steps towards interop testing and the related topic of settling some applications / profiles. This may also lead to the topic of WG charter or wrap. If there are others here in Adelaide who would like to put together something on this for presentation at the meeting, please look me up and we can work on that together. Otherwise, I guess we wing it verbally. I will also put together a 1-2 slide summary of where we appear to be with the Megaco IP Phone application profile specifically, and the case for progressing it in the WG. BTW, Do we know where we stand on Megaco MIB? -- Peter Blatherwick > -----Original Message----- > From: Taylor, Tom-PT [CAR:B904:EXCH] > Sent: Sunday, March 26, 2000 1:47 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Agenda For Melbourne > > My E-mail connectivity hasn't been what I hoped -- I don't even know if > this > message will get off. I can only be sure of being able to connect when I > get to Adelaide Sunday afternoon. As a result, I didn't manage to do up > an > agenda by the official deadline. This is a first cut, with a final one to > be set Sunday after I have feedback from you. > > Meeting Thursday morning 9:00-11:30 > > 09:00-09:05 Agenda bashing > 09:05-10:15 Base protocol open items > Objective: close on required changes to > draft-ietf-megaco-protocol-07.txt > (subject to Study Group 16 concurrence) > 10:15-11:15 Other work items > Objective: identify open issues (if any) and whether Last Call should be > issued > 11:15-11:30 WG recharter/wrapup? > > I will issue a summary of base protocol status by Sunday evening, > reflecting > the Last Call discussions. > > "Other work items" include the following: > > draft-ietf-megaco-ipphone-02.txt > Something on ATM, I assume. > draft-ietf-megaco-naspkg-00.txt > draft-bouwen-megaco-isdn-00.txt > draft-brown-supplpkgs-00.txt > draft-ietf-megaco-R2package-00.txt (needs refreshing!) > draft-ietf-megaco-mib-00.txt (if no progress, we won't discuss) > > Let me know what else should be here or alternative suggestions for the > agenda. All drafts can be found at > http://www.ietf.org/internet-drafts/ > > Tom Taylor > Advisor -- Emerging Carrier IP Standards > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) > Phone and FAX: +1 613 736 0961 ------_=_NextPart_001_01BF9899.072FD33A Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Agenda For Melbourne

Tom, list:

As we discussed in the hall = here yesterday, Zach, Mike and I have put together a quick overview of = status and content overview of the package definitions that exist so = far, including the ones you list below and all ITU defined = packages.   Hopefully we did not miss any -- its a bit = confusing.  Should not need more than 5-10 minutes to = present.  We think its useful to go over these as a lead in to = some quick discussion on how to handle these in IETF documentation = (if/when/how these move to RFC or whatever).  Hopefully this = helps. 

There is also seems to be a = need for some discussion of steps towards interop testing and the = related topic of settling some applications / profiles.  This may = also lead to the topic of WG charter or wrap.  If there are others = here in Adelaide who would like to put together something on this for = presentation at the meeting, please look me up and we can work on that = together.  Otherwise, I guess we wing it verbally.  =

I will also put together a = 1-2 slide summary of where we appear to be with the Megaco IP Phone = application profile specifically, and the case for progressing it in = the WG. 

BTW, Do we know where we = stand on Megaco MIB? 

-- Peter Blatherwick



    -----Original Message-----
    From:   Taylor, Tom-PT [CAR:B904:EXCH]
    Sent:   Sunday, March 26, 2000 1:47 AM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Agenda For Melbourne

    My E-mail connectivity hasn't been = what I hoped -- I don't even know if this
    message will get off.  I can = only be sure of being able to connect when I
    get to Adelaide Sunday = afternoon.  As a result, I didn't manage to do up an
    agenda by the official = deadline.  This is a first cut, with a final one to
    be set Sunday after I have feedback = from you.

    Meeting Thursday morning = 9:00-11:30

    09:00-09:05 Agenda bashing
    09:05-10:15 Base protocol open = items
      Objective: close on required = changes to draft-ietf-megaco-protocol-07.txt
    (subject to Study Group 16 = concurrence)
    10:15-11:15 Other work items
      Objective: identify open = issues (if any) and whether Last Call should be
    issued
    11:15-11:30 WG = recharter/wrapup?

    I will issue a summary of base = protocol status by Sunday evening, reflecting
    the Last Call discussions.

    "Other work items" include = the following:

      = draft-ietf-megaco-ipphone-02.txt
      Something on ATM, I = assume.
      = draft-ietf-megaco-naspkg-00.txt
      = draft-bouwen-megaco-isdn-00.txt
      = draft-brown-supplpkgs-00.txt
      = draft-ietf-megaco-R2package-00.txt (needs refreshing!)
      draft-ietf-megaco-mib-00.txt = (if no progress, we won't discuss)

    Let me know what else should be here = or alternative suggestions for the
    agenda.  All drafts can be found = at
     http://www.ietf.org/internet-drafts/<draft name>

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

------_=_NextPart_001_01BF9899.072FD33A-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 28 04:54:58 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18918 for ; Tue, 28 Mar 2000 04:40:50 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F6AD24B0@standards.nortelnetworks.com>; Tue, 28 Mar 2000 4:34:54 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 106995 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Mar 2000 04:34:33 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.84B2F0C0@standards.nortelnetworks.com>; Tue, 28 Mar 2000 4:24:33 -0500 Received: from cisco.com (oz-syd-dial1-23.cisco.com [144.254.157.24]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id BAA28446; Tue, 28 Mar 2000 01:29:20 -0800 (PST) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <38D98F8F.35A2C799@ericsson.com> <38DF73C7.D2D33E39@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38E00176.F5A80ED6@cisco.com> Date: Mon, 27 Mar 2000 16:48:55 -0800 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Subject: Re: V16 review - Editorial comments X-To: John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit John Segers wrote: > Some more comments. Please see below. > > John > > Christian Groves wrote: > > > > G'Day Nancy, > > > > Please see my comments marked [CHG]. > > > > Cheers, Christian > > > > Nancy-M Greene wrote: > > > > > > Brian, John, > > > I believe each of the following is an editorial change to V16. You > > > have both seen most of these already, and commented on them - I am > > > posting them to the megaco list this time, with the proposed > > > resolutions. Please comment! > > > > > > 1- Section 7.1.1 Specifying Parameters > > > Issue: para. starting with "Unspecified mandatory parameters > > > (i.e. mandatory parameters not specified in a descriptor) result > > > in the command responder retaining the previous value for that > > > parameter." > > > > > > Comment: It seems that this section applies only to mandatory fields > > > in > > > Local and Remote descriptors (see section 7.1.8). For example, when > > > a mandatory parameter is unspecified in the Local descriptor, > > > then it retains the value it already has. But, a mandatory parameter > > > in a ServiceChange HAS to be there I would think. For example, the > > > ServiceChangeMethod descriptor is mandatory, and must > > > always be present. > > > > > > Proposal: Preface the quoted sentence in 7.1.1 with "For Local and > > > Remote Descriptors, unspecified mandatory parameters (i.e. mandatory > > > parameters not specified in a descriptor) result in the ...." > > I'm not sure that local and remote are the exceptions, or > ServiceChange. Maybe we could say that if there is a previous value, it > is retained. If there is not, then you generate an error message. Seems to be more complicated than necessary. I would much prefer to define all parameters to be empty initially and just leave it at that. -- Flemming -- Flemming Andreasen Phone: +1 732 452 1667 Cisco Systems Fax: +1 240 359 5839 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 28 05:34:31 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19314 for ; Tue, 28 Mar 2000 05:34:30 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.87F05260@standards.nortelnetworks.com>; Tue, 28 Mar 2000 5:29:04 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 107145 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Mar 2000 05:27:24 -0500 Received: from smtprtp1.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E69CFEA0@standards.nortelnetworks.com>; Tue, 28 Mar 2000 5:17:24 -0500 Received: from zcard015.ca.nortel.com (actually zcard015) by smtprtp1.ntcom.nortel.net; Tue, 28 Mar 2000 05:15:52 -0500 Received: from zrtpd00z.us.nortel.com ([47.140.224.110]) by zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HAZ4P5WB; Tue, 28 Mar 2000 05:15:48 -0500 Received: from nortelnetworks.com (PMERY0H8 [47.182.199.186]) by zrtpd00z.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HSZ9D3BJ; Tue, 28 Mar 2000 05:15:46 -0500 X-Sybari-Space: 00000000 00000000 00000000 X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 References: <29400B68197CD31188830000F8CD15D343BCEE@zcard00q.ca.nortel.com> Content-Type: multipart/alternative; boundary="------------03292949364D42178B1FA7B6" Message-ID: <38E086F3.A18548F6@nortelnetworks.com> Date: Tue, 28 Mar 2000 05:18:27 -0500 Reply-To: Michael Brown Sender: "Media Gateway Control (megaco)" From: Michael Brown Organization: Nortel Networks Subject: Re: Agenda For Melbourne X-To: Peter Blatherwick X-cc: Tom-PT Taylor , Bilalis Zacharias To: MEGACO@STANDARDS.NORTELNETWORKS.COM --------------03292949364D42178B1FA7B6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Peter, Interesting to be communicating on the list across town here in Adelaide... Just a quick comment about the status on the MIB. I have been working with some others at Nortel to create a new version of the Megaco MIB which is based on the original I-D. We have added a number of things to it and changed a few things. I had hoped we would be able to complete the work on our proposal in time to submit it for discussion here in Adelaide, but we just missed the deadline. I have a copy of it with me here, but I haven't put it in I-D format. I had intended to do that and post it, but really haven't had time to do it being here at the meeting. I will try to get it done in the next day or so, but regardless will definitely have it posted by early next week. Cheers, Mike "Blatherwick, Peter (P.) [EXCHANGE:CAR:AT14]" wrote: > > > Tom, list: > > As we discussed in the hall here yesterday, Zach, Mike and I have put > together a quick overview of status and content overview of the > package definitions that exist so far, including the ones you list > below and all ITU defined packages. Hopefully we did not miss any -- > its a bit confusing. Should not need more than 5-10 minutes to > present. We think its useful to go over these as a lead in to some > quick discussion on how to handle these in IETF documentation > (if/when/how these move to RFC or whatever). Hopefully this helps. > > There is also seems to be a need for some discussion of steps towards > interop testing and the related topic of settling some applications / > profiles. This may also lead to the topic of WG charter or wrap. If > there are others here in Adelaide who would like to put together > something on this for presentation at the meeting, please look me up > and we can work on that together. Otherwise, I guess we wing it > verbally. > > I will also put together a 1-2 slide summary of where we appear to be > with the Megaco IP Phone application profile specifically, and the > case for progressing it in the WG. > > BTW, Do we know where we stand on Megaco MIB? > > -- Peter Blatherwick > > > -----Original Message----- > From: Taylor, Tom-PT [CAR:B904:EXCH] > Sent: Sunday, March 26, 2000 1:47 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Agenda For Melbourne > > My E-mail connectivity hasn't been what I hoped -- I don't even > know if this > message will get off. I can only be sure of being able to > connect when I > get to Adelaide Sunday afternoon. As a result, I didn't manage > to do up an > agenda by the official deadline. This is a first cut, with a > final one to > be set Sunday after I have feedback from you. > > Meeting Thursday morning 9:00-11:30 > > 09:00-09:05 Agenda bashing > 09:05-10:15 Base protocol open items > Objective: close on required changes to > draft-ietf-megaco-protocol-07.txt > (subject to Study Group 16 concurrence) > 10:15-11:15 Other work items > Objective: identify open issues (if any) and whether Last Call > should be > issued > 11:15-11:30 WG recharter/wrapup? > > I will issue a summary of base protocol status by Sunday evening, > reflecting > the Last Call discussions. > > "Other work items" include the following: > > draft-ietf-megaco-ipphone-02.txt > Something on ATM, I assume. > draft-ietf-megaco-naspkg-00.txt > draft-bouwen-megaco-isdn-00.txt > draft-brown-supplpkgs-00.txt > draft-ietf-megaco-R2package-00.txt (needs refreshing!) > draft-ietf-megaco-mib-00.txt (if no progress, we won't discuss) > > Let me know what else should be here or alternative suggestions > for the > agenda. All drafts can be found at > http://www.ietf.org/internet-drafts/ > > Tom Taylor > Advisor -- Emerging Carrier IP Standards > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) > Phone and FAX: +1 613 736 0961 > --------------03292949364D42178B1FA7B6 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Peter,

  Interesting to be communicating on the list across town here in Adelaide...

  Just a quick comment about the status on the MIB. I have been working with some others at Nortel to create a new version of the Megaco MIB which is based on the original I-D. We have added a number of things to it and changed a few things. I had hoped we would be able to complete the work on our proposal in time to submit it for discussion here in Adelaide, but we just missed the deadline.

  I have a copy of it with me here, but I haven't put it in I-D format.  I had intended to do that and post it, but really haven't had time to do it being here at the meeting. I will try to get it done in the next day or so, but regardless will definitely have it posted by early next week.

Cheers,

Mike
 
 

"Blatherwick, Peter (P.) [EXCHANGE:CAR:AT14]" wrote:

 

Tom, list:

As we discussed in the hall here yesterday, Zach, Mike and I have put together a quick overview of status and content overview of the package definitions that exist so far, including the ones you list below and all ITU defined packages.   Hopefully we did not miss any -- its a bit confusing.  Should not need more than 5-10 minutes to present.  We think its useful to go over these as a lead in to some quick discussion on how to handle these in IETF documentation (if/when/how these move to RFC or whatever).  Hopefully this helps.

There is also seems to be a need for some discussion of steps towards interop testing and the related topic of settling some applications / profiles.  This may also lead to the topic of WG charter or wrap.  If there are others here in Adelaide who would like to put together something on this for presentation at the meeting, please look me up and we can work on that together.  Otherwise, I guess we wing it verbally.

I will also put together a 1-2 slide summary of where we appear to be with the Megaco IP Phone application profile specifically, and the case for progressing it in the WG.

BTW, Do we know where we stand on Megaco MIB?

-- Peter Blatherwick
 

    -----Original Message-----
    From:   Taylor, Tom-PT [CAR:B904:EXCH]
    Sent:   Sunday, March 26, 2000 1:47 AM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:        Agenda For Melbourne

    My E-mail connectivity hasn't been what I hoped -- I don't even know if this
    message will get off.  I can only be sure of being able to connect when I
    get to Adelaide Sunday afternoon.  As a result, I didn't manage to do up an
    agenda by the official deadline.  This is a first cut, with a final one to
    be set Sunday after I have feedback from you.

    Meeting Thursday morning 9:00-11:30

    09:00-09:05 Agenda bashing
    09:05-10:15 Base protocol open items
      Objective: close on required changes to draft-ietf-megaco-protocol-07.txt
    (subject to Study Group 16 concurrence)
    10:15-11:15 Other work items
      Objective: identify open issues (if any) and whether Last Call should be
    issued
    11:15-11:30 WG recharter/wrapup?

    I will issue a summary of base protocol status by Sunday evening, reflecting
    the Last Call discussions.

    "Other work items" include the following:

      draft-ietf-megaco-ipphone-02.txt
      Something on ATM, I assume.
      draft-ietf-megaco-naspkg-00.txt
      draft-bouwen-megaco-isdn-00.txt
      draft-brown-supplpkgs-00.txt
      draft-ietf-megaco-R2package-00.txt (needs refreshing!)
      draft-ietf-megaco-mib-00.txt (if no progress, we won't discuss)

    Let me know what else should be here or alternative suggestions for the
    agenda.  All drafts can be found at
     http://www.ietf.org/internet-drafts/<draft name>

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

--------------03292949364D42178B1FA7B6-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 28 09:34:54 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21447 for ; Tue, 28 Mar 2000 09:34:53 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.1DE3E9F0@standards.nortelnetworks.com>; Tue, 28 Mar 2000 9:29:29 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 107467 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Mar 2000 09:28:23 -0500 Received: from ihemlsrv.firewall.lucent.com (192.11.222.161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.F6C3E460@standards.nortelnetworks.com>; Tue, 28 Mar 2000 9:28:23 -0500 Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA20471 for ; Tue, 28 Mar 2000 09:33:15 -0500 (EST) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA20451 for ; Tue, 28 Mar 2000 09:33:14 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA07300; Tue, 28 Mar 2000 16:33:13 +0200 (MET DST) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA07296; Tue, 28 Mar 2000 16:33:13 +0200 (MET DST) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <38D98F8F.35A2C799@ericsson.com> <38DF73C7.D2D33E39@lucent.com> <38E00176.F5A80ED6@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38E0C296.FA86ED9B@lucent.com> Date: Tue, 28 Mar 2000 16:32:54 +0200 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: V16 review - Editorial comments To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Flemming, I have no objection to that. John Flemming Andreasen wrote: [snip] > > > > Proposal: Preface the quoted sentence in 7.1.1 with "For Local and > > > > Remote Descriptors, unspecified mandatory parameters (i.e. mandatory > > > > parameters not specified in a descriptor) result in the ...." > > > > I'm not sure that local and remote are the exceptions, or > > ServiceChange. Maybe we could say that if there is a previous value, it > > is retained. If there is not, then you generate an error message. > > Seems to be more complicated than necessary. I would much prefer to define all > parameters to be empty initially and just leave it at that. > > -- Flemming > > -- > Flemming Andreasen Phone: +1 732 452 1667 > Cisco Systems Fax: +1 240 359 5839 -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 28 12:26:27 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23956 for ; Tue, 28 Mar 2000 12:26:27 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0DAAB2E0@standards.nortelnetworks.com>; Tue, 28 Mar 2000 12:20:50 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 107726 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Mar 2000 12:19:02 -0500 Received: from eagle.aud.alcatel.com (128.251.96.217) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.679E9200@standards.nortelnetworks.com>; Tue, 28 Mar 2000 12:09:01 -0500 Received: from aud.alcatel.com by eagle.aud.alcatel.com (8.8.8+Sun/SMI-SVR4) id LAA12026; Tue, 28 Mar 2000 11:13:46 -0600 (CST) X-Mailer: Mozilla 4.5 [en]C-ANS 1.02 (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <38DF9548.F3D3A998@ficon-tech.com> <38E00357.6E68F710@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38E0E896.E46769A3@aud.alcatel.com> Date: Tue, 28 Mar 2000 11:15:02 -0600 Reply-To: James Hua Sender: "Media Gateway Control (megaco)" From: James Hua Organization: Alcatel USA Subject: unsubscrible To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit How can I unsubscrible this mailing list? Thanks From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 28 13:14:18 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24557 for ; Tue, 28 Mar 2000 13:14:18 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C6A86DE0@standards.nortelnetworks.com>; Tue, 28 Mar 2000 13:08:57 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 107801 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Mar 2000 13:07:57 -0500 Received: from mw.3com.com (149.112.20.3) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.3D2EE810@standards.nortelnetworks.com>; Tue, 28 Mar 2000 12:57:57 -0500 Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation) id MAA11229; Tue, 28 Mar 2000 12:02:44 -0600 (CST) Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) id 862568B0.00634767 ; Tue, 28 Mar 2000 12:04:23 -0600 X-Lotus-FromDomain: 3COM@3COM-MWGATE Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <862568B0.00634679.00@mwgate02.mw.3com.com> Date: Tue, 28 Mar 2000 12:04:30 -0600 Reply-To: Yu Zhu Sender: "Media Gateway Control (megaco)" From: Yu Zhu Subject: DTMF detection X-cc: Pankaj Garg To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi there, The MG shall support detecting and passing DTMF signals to the peer gateway. The MG can use various methods in order to transport DTMF depending on its configuration and instructions by the MGC. The three different types of mechanisms for transport of DTMF are : 1). To the MGC through the standard MEGACO DTMF package 2) In-band in the RTP stream and 3) Out-of-band through a special payload type in the RTP stream (per the Internet-draft "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals") In case of sending the DTMF trough the MGC and also when sending it with special RTP payloads as defined in the latest IETF draft , Should the DTMF be extracted from the media stream and replaced with comfort noise ? If someone chooses to use the special RTP packets and extracts DTMF out of media stream, how is it determined that the other end supports the same mechanism ? Regards, -- Yu Zhu From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 28 13:22:26 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24614 for ; Tue, 28 Mar 2000 13:22:26 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E828D350@standards.nortelnetworks.com>; Tue, 28 Mar 2000 13:17:03 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 107885 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Mar 2000 13:15:04 -0500 Received: from rambo.globespan.net (209.191.59.250) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A10FFD40@standards.nortelnetworks.com>; Tue, 28 Mar 2000 13:15:03 -0500 Received: from ficon-tech.com (phoenix.ficon-tech.com [209.125.90.2]) by rambo.globespan.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HSWZVTLH; Tue, 28 Mar 2000 13:17:39 -0500 X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <38DFC606.93C0AFC9@ficon-tech.com> <38E071BD.8FABF9D7@lucent.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <38E0F651.D07A9577@ficon-tech.com> Date: Tue, 28 Mar 2000 13:13:37 -0500 Reply-To: Harpreet Singh Anand Sender: "Media Gateway Control (megaco)" From: Harpreet Singh Anand Subject: Re: v16 comments: digit map X-To: John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hello John, John Segers wrote: > 1. The "T" timer is used to override the default start timer. My question was not on configuring the value of Start timer. The text in the draft says "The Start timer is started at the beginning of every digit map use, but can be overridden.”. This means that MGC can configure whether MG should start the start timer or not. My question was how to configure this. Is it by setting a value of 0 ? Regards, Harpreet From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 28 13:26:36 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24635 for ; Tue, 28 Mar 2000 13:26:35 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.79B28410@standards.nortelnetworks.com>; Tue, 28 Mar 2000 13:21:07 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 107934 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Mar 2000 13:19:14 -0500 Received: from rambo.globespan.net (209.191.59.250) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.36808520@standards.nortelnetworks.com>; Tue, 28 Mar 2000 13:19:14 -0500 Received: from ficon-tech.com (phoenix.ficon-tech.com [209.125.90.2]) by rambo.globespan.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id HSWZVTMD; Tue, 28 Mar 2000 13:21:51 -0500 X-Mailer: Mozilla 4.6 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <38DF9548.F3D3A998@ficon-tech.com> <38E00357.6E68F710@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38E0F74B.3D68DC5@ficon-tech.com> Date: Tue, 28 Mar 2000 13:17:47 -0500 Reply-To: Harpreet Singh Anand Sender: "Media Gateway Control (megaco)" From: Harpreet Singh Anand Subject: Re: v16 comments: Event Handling X-To: Flemming Andreasen To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello, > At the risk of oversimplifying here, I think this boils down to which of > these parameters are mandatory and which are optional. It would be *really* > nice if we could get a table or something containing all the parameters and > indicating for each if it's mandatory or optional. Actually each of the case given below can be avoided if certain triggers are defined as invalid in some state. It would be good if these clarifications are added either in the draft itself or in the implementor's guide. Regards, Harpreet > > > -- Flemming > > Harpreet Singh Anand wrote: > > > Hello all, > > > > The description for event handling in Sec 7.1.9 needs to be clarified > > for the following states: > > > > (a) Consider the state when Event Bfr Control (EBC) is LockStep and Mg > > is collecting events according to EventBuffer Descriptor (EBD). If in > > this state MG receives a command which sets EBC to Off (and the command > > does not contain any new ED), then what should MG do? Should the MG > > - flush event buffer queue and start collecting events according to > > the last ED that was set. OR > > - Flush event buffer and keep on collecting events according to EBD. > > > > (b) Consider the state when Event Bfr Control (EBC) is LockStep and Mg > > is collecting events according to EventBuffer Descriptor (EBD). If in > > this state MG receives a command which sets a new EBD, then what should > > MG do? Should the MG > > > > - flush the event bfr queue and start collecting events according to > > the new EBD OR > > - keep the events in the bfr q. which correspond to the EBD and > > remove other events and start collecting events according to the new EBD > > OR > > - does not flush the event q and start collecting events according > > to the new EBD > > > > (c) Consider the state when Event Bfr Control (EBC) is LockStep and Mg > > is collecting events according to Event Descriptor (ED). Also consider > > that at this time EBD is not specified. If in this state MG receives an > > event which matches an event in the ED. The MG would send the Notify > > command request. If EBD would have been specified then the MG would have > > started collecting events according to the EBD. But if the EBD is not > > specified, then what should MG do ? Should the MG > > > > - Remain in the same state and keep on collecting according to the > > current ED ? OR > > - Stop collecting events as EBD is not available. > > > > Regards, > > Harpreet > > -- > Flemming Andreasen Phone: +1 732 452 1667 > Cisco Systems Fax: +1 240 359 5839 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 28 15:26:45 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26009 for ; Tue, 28 Mar 2000 15:26:44 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.4820C9A0@standards.nortelnetworks.com>; Tue, 28 Mar 2000 15:21:25 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 108159 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Mar 2000 15:19:31 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9E005900@standards.nortelnetworks.com>; Tue, 28 Mar 2000 15:09:30 -0500 Received: from cisco.com (oz-syd-dial1-3.cisco.com [144.254.157.4]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id MAA28664; Tue, 28 Mar 2000 12:14:18 -0800 (PST) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <38DF9548.F3D3A998@ficon-tech.com> <38E00357.6E68F710@cisco.com> <38E0F74B.3D68DC5@ficon-tech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38E13D64.DCB3ED5A@cisco.com> Date: Tue, 28 Mar 2000 15:16:52 -0800 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Subject: Re: v16 comments: Event Handling X-To: Harpreet Singh Anand To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Harpreet Singh Anand wrote: > Hello, > > > At the risk of oversimplifying here, I think this boils down to which of > > these parameters are mandatory and which are optional. It would be *really* > > nice if we could get a table or something containing all the parameters and > > indicating for each if it's mandatory or optional. > > Actually each of the case given below can be avoided if certain triggers are > defined as invalid in some state. It would be good if these clarifications are > added either in the draft itself or in the implementor's guide. > My point is that we should *not* try to do that. Rather than all of us trying to figure out and agree which combinations of parameters make sense and design that into the protocol, you design a general solution that has a clear and well-defined behavior in all cases. If there are combinations you don't find useful, your MGC will simply not use those. > > Regards, > Harpreet > -- Flemming > > > > > > > -- Flemming > > > > Harpreet Singh Anand wrote: > > > > > Hello all, > > > > > > The description for event handling in Sec 7.1.9 needs to be clarified > > > for the following states: > > > > > > (a) Consider the state when Event Bfr Control (EBC) is LockStep and Mg > > > is collecting events according to EventBuffer Descriptor (EBD). If in > > > this state MG receives a command which sets EBC to Off (and the command > > > does not contain any new ED), then what should MG do? Should the MG > > > - flush event buffer queue and start collecting events according to > > > the last ED that was set. OR > > > - Flush event buffer and keep on collecting events according to EBD. > > > > > > (b) Consider the state when Event Bfr Control (EBC) is LockStep and Mg > > > is collecting events according to EventBuffer Descriptor (EBD). If in > > > this state MG receives a command which sets a new EBD, then what should > > > MG do? Should the MG > > > > > > - flush the event bfr queue and start collecting events according to > > > the new EBD OR > > > - keep the events in the bfr q. which correspond to the EBD and > > > remove other events and start collecting events according to the new EBD > > > OR > > > - does not flush the event q and start collecting events according > > > to the new EBD > > > > > > (c) Consider the state when Event Bfr Control (EBC) is LockStep and Mg > > > is collecting events according to Event Descriptor (ED). Also consider > > > that at this time EBD is not specified. If in this state MG receives an > > > event which matches an event in the ED. The MG would send the Notify > > > command request. If EBD would have been specified then the MG would have > > > started collecting events according to the EBD. But if the EBD is not > > > specified, then what should MG do ? Should the MG > > > > > > - Remain in the same state and keep on collecting according to the > > > current ED ? OR > > > - Stop collecting events as EBD is not available. > > > > > > Regards, > > > Harpreet > > > > -- > > Flemming Andreasen Phone: +1 732 452 1667 > > Cisco Systems Fax: +1 240 359 5839 -- Flemming Andreasen Phone: +1 732 452 1667 Cisco Systems Fax: +1 240 359 5839 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 28 18:14:40 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28311 for ; Tue, 28 Mar 2000 18:14:39 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.877E4980@standards.nortelnetworks.com>; Tue, 28 Mar 2000 18:07:50 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 108451 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Mar 2000 18:06:19 -0500 Received: from drawbridge.ascend.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.EBCB15A0@standards.nortelnetworks.com>; Tue, 28 Mar 2000 17:56:19 -0500 Received: from fw-ext.ascend.com (fw-ext [198.4.92.5]) by drawbridge.ascend.com (8.9.1a/8.9.1) with SMTP id OAA05791; Tue, 28 Mar 2000 14:54:24 -0800 (PST) Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for drawbridge.ascend.com [198.4.92.1]) with SMTP; 28 Mar 2000 23:00:59 UT Received: from porky (porky.ascend.com [192.207.23.83]) by russet.ascend.com (8.9.1a/8.9.1) with ESMTP id PAA24428; Tue, 28 Mar 2000 15:00:58 -0800 (PST) Received: from ascend.com by ascend.com X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 References: <29400B68197CD31188830000F8CD15D343BCEE@zcard00q.ca.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.2.2.20000328145736.00bce780@porky> Date: Tue, 28 Mar 2000 15:00:25 -0800 Reply-To: Matt Holdrege Sender: "Media Gateway Control (megaco)" From: Matt Holdrege Subject: Re: Agenda For Melbourne X-To: Michael Brown To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <38E086F3.A18548F6@nortelnetworks.com> Michael, It would be good to feed that data in to us as we prepare the next MIB draft. We have some of the work done, but weren't able to get a draft out in time for probably the same reasons as you. We've asked the list for input, but this is the first I've heard back of any interest. Look forward to reading your work. At 05:18 AM 3/28/00 -0500, Michael Brown wrote: >Peter, > > Interesting to be communicating on the list across town here in > Adelaide... > > Just a quick comment about the status on the MIB. I have been working > with some others at Nortel to create a new version of the Megaco MIB > which is based on the original I-D. We have added a number of things to > it and changed a few things. I had hoped we would be able to complete the > work on our proposal in time to submit it for discussion here in > Adelaide, but we just missed the deadline. > > I have a copy of it with me here, but I haven't put it in I-D > format. I had intended to do that and post it, but really haven't had > time to do it being here at the meeting. I will try to get it done in the > next day or so, but regardless will definitely have it posted by early > next week. > >Cheers, > >Mike > > > >"Blatherwick, Peter (P.) [EXCHANGE:CAR:AT14]" wrote: >> >> >>Tom, list: >> >>As we discussed in the hall here yesterday, Zach, Mike and I have put >>together a quick overview of status and content overview of the package >>definitions that exist so far, including the ones you list below and all >>ITU defined packages. Hopefully we did not miss any -- its a bit >>confusing. Should not need more than 5-10 minutes to present. We think >>its useful to go over these as a lead in to some quick discussion on how >>to handle these in IETF documentation (if/when/how these move to RFC or >>whatever). Hopefully this helps. >> >>There is also seems to be a need for some discussion of steps towards >>interop testing and the related topic of settling some applications / >>profiles. This may also lead to the topic of WG charter or wrap. If >>there are others here in Adelaide who would like to put together >>something on this for presentation at the meeting, please look me up and >>we can work on that together. Otherwise, I guess we wing it verbally. >> >>I will also put together a 1-2 slide summary of where we appear to be >>with the Megaco IP Phone application profile specifically, and the case >>for progressing it in the WG. >> >>BTW, Do we know where we stand on Megaco MIB? >> >>-- Peter Blatherwick >> >>-----Original Message----- From: Taylor, Tom-PT >>[CAR:B904:EXCH] Sent: Sunday, March 26, 2000 1:47 >>AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Agenda >>For Melbourne >> >>My E-mail connectivity hasn't been what I hoped -- I don't even know if >>this message will get off. I can only be sure of being able to connect >>when I get to Adelaide Sunday afternoon. As a result, I didn't manage >>to do up an agenda by the official deadline. This is a first cut, with >>a final one to be set Sunday after I have feedback from you. >> >>Meeting Thursday morning 9:00-11:30 >> >>09:00-09:05 Agenda bashing 09:05-10:15 Base protocol open >>items Objective: close on required changes to >>draft-ietf-megaco-protocol-07.txt (subject to Study Group 16 >>concurrence) 10:15-11:15 Other work items Objective: identify open >>issues (if any) and whether Last Call should be issued 11:15-11:30 WG >>recharter/wrapup? >> >>I will issue a summary of base protocol status by Sunday evening, >>reflecting the Last Call discussions. >> >>"Other work items" include the following: >> >> draft-ietf-megaco-ipphone-02.txt Something on ATM, I >> assume. draft-ietf-megaco-naspkg-00.txt >> draft-bouwen-megaco-isdn-00.txt draft-brown-supplpkgs-00.txt >> draft-ietf-megaco-R2package-00.txt (needs >> refreshing!) draft-ietf-megaco-mib-00.txt (if no progress, we won't >> discuss) >> >>Let me know what else should be here or alternative suggestions for >>the agenda. All drafts can be found >>at >>http://www.ietf.org/internet-drafts/ >> >> >>Tom Taylor Advisor -- Emerging Carrier IP Standards E-mail: >>taylor@nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 >>613 736 0961 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 28 19:27:22 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00306 for ; Tue, 28 Mar 2000 19:27:22 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.E70EA890@standards.nortelnetworks.com>; Tue, 28 Mar 2000 19:22:05 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 108556 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Mar 2000 19:20:31 -0500 Received: from mailgate.fore.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.48F91AB0@standards.nortelnetworks.com>; Tue, 28 Mar 2000 19:10:30 -0500 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id TAA19762; Tue, 28 Mar 2000 19:15:17 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id TAA19586; Tue, 28 Mar 2000 19:15:19 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Mar 2000 19:10:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF6780AD@whq-msgusr-02.fore.com> Date: Tue, 28 Mar 2000 19:15:17 -0500 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: DTMF detection X-To: Yu Zhu To: MEGACO@STANDARDS.NORTELNETWORKS.COM I'm inclined to declare this issue out of scope of Megaco, as it only deals with what happens in the media stream and has nothing to do with the control of the streams or the connections. I personally think that you would NOT substitute comfort noise in any conditions. Determining support of an RTP payload capability in the MG is possible with the standard Megaco audit capabilities mechanism. How two MGCs determine whether the opposite MG can do it is an interMGC protocol issue, and clearly out of scope of Megaco. Brian > -----Original Message----- > From: Yu Zhu [mailto:Yu_Zhu@MW.3COM.COM] > Sent: Tuesday, March 28, 2000 1:05 PM > To: MEGACO@standards.nortelnetworks.com > Subject: DTMF detection > > > Hi there, > > The MG shall support detecting and passing DTMF signals to > the peer gateway. The > MG can use various methods in order to transport DTMF depending on its > configuration and instructions by the MGC. > The three different types of mechanisms for transport of DTMF are : > 1). To the MGC through the standard MEGACO DTMF package > 2) In-band in the RTP stream and > 3) Out-of-band through a special payload type in the RTP > stream (per the > Internet-draft "RTP Payload for DTMF Digits, Telephony Tones > and Telephony > Signals") > > In case of sending the DTMF trough the MGC and also when > sending it with special > RTP payloads as defined in the latest IETF draft , Should the > DTMF be extracted > from the media stream and replaced with comfort noise ? If > someone chooses to > use the special RTP packets and extracts DTMF out of media > stream, how is it > determined that the other end supports the same mechanism ? > > Regards, > -- Yu Zhu > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 28 20:34:30 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00985 for ; Tue, 28 Mar 2000 20:34:29 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.481C0020@standards.nortelnetworks.com>; Tue, 28 Mar 2000 20:29:13 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 108700 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Mar 2000 20:27:35 -0500 Received: from smtprich.nortel.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0D426340@standards.nortelnetworks.com>; Tue, 28 Mar 2000 20:27:35 -0500 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprich.nortel.com; Tue, 28 Mar 2000 19:33:00 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Mar 2000 19:32:03 -0600 X-Mailer: Internet Mail Service (5.5.2650.21) X-Orig: Message-ID: Date: Tue, 28 Mar 2000 19:32:03 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Proposed ADELAIDE Agenda (revised) To: MEGACO@STANDARDS.NORTELNETWORKS.COM Discussion here in Adelaide and review of activity on the list has suggested that we need to spend less time on the base protocol document and more on looking forward. To that end, here is a revised proposal for the meeting agenda tomorrow morning. Broad outline: 09:00 - 09:05 Agenda bashing 09:05 - 09:15 Status review (Taylor, Bilalis, Blatherwick?) 09:15 - 09:45 Looking forward (detailed list of issues below) (Taylor) 09:45 - 09:55 Interoperability plans (Rosen, Taylor) 09:55 - 10:25 Current work draft-ietf-megaco-ipphone-02.txt (Blatherwick) draft-ietf-megaco-naspkg-00.txt (Taylor) draft-ietf-megaco-R2package-00.txt (??) draft-ietf-megaco-mib-00.txt (Holdrege, Brown) 10:25-10:50 Potential future work draft-brown-supplpkgs-00.txt (Brown) draft-bouwen-megaco-isdn-00.txt (Van Doorselaer) draft [ATM] draft-ricagni-megaco-umts-all-ip-00.txt (Ricagni) Other suggestions? 10:50-11:30 Review of proposed corrections to base document (Taylor) Issues looking forward: (1) Base protocol evolution: -- what process for IETF participation? -- what does the IETF publish? -- do we apply IETF process to take Megaco v1 to Draft Standard? (2) Packages: -- what track? Decision on per-case basis? -- what process for publishing ITU-generated packages? -- what process for creating IETF-generated packages? (3) Profiles: -- who creates? -- registration process? Bottom line: does IETF wish to continue to participate in Megaco/H.248 development? If so, should Megaco continue to exist, should offshoot WGs be constituted as needed, or should everything be handled at the IESG level? Tom Taylor Advisor -- Emerging Carrier IP Standards E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Mar 28 20:38:40 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01064 for ; Tue, 28 Mar 2000 20:38:40 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.D850CF40@standards.nortelnetworks.com>; Tue, 28 Mar 2000 20:33:15 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 108681 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 28 Mar 2000 20:31:22 -0500 Received: from ish7.ericsson.com.au (203.61.155.111) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2EC8F520@standards.nortelnetworks.com>; Tue, 28 Mar 2000 20:21:21 -0500 Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id LAA28442; Wed, 29 Mar 2000 11:24:35 +1000 (EST) Received: from mcsi00.epa.ericsson.se (mcsi00 [146.11.8.201]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id LAA02716; Wed, 29 Mar 2000 11:25:19 +1000 (EST) Received: from ericsson.com (7-137.epa.ericsson.se [146.11.7.137]) by mcsi00.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id LAA29681; Wed, 29 Mar 2000 11:24:32 +1000 (EST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38E15B42.6EEF9056@ericsson.com> Date: Wed, 29 Mar 2000 11:24:18 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: FW: new proposed TIPHON work items X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Tom, I think going for the Tiphon PICS is a bit premature for a first interop test. Some people may not be interested in Tiphon GWs (I'm thinking of you Pete :-)). I'm sure this will come up in discussions in Adelaide. Cheers, Christian > Tom-PT Taylor wrote: > > Megaco followers may have an interest in this one, considering the > recent > discussions on interoperability testing. Is this a valid work item, > is it > premature, is it a necessary step? Comments? > > > -----Original Message----- > > From: Schink Helmut [SMTP:Helmut.Schink@icn.siemens.de] > > Sent: Thursday, March 23, 2000 7:40 AM > > To: new-work@ietf.org > > Cc: 'TIPHON_PMC' > > Subject: new proposed TIPHON work items > > > > A series of new work items have been proposed at the TIPHON#17 > meeting: > > TIPHON has not made any determination as yet. The following titles > have > > submitted: > > > [[TomT]] ... > > 11.Protocol Implementation Conformance Statement (PICS) proforma > for the > > support of physically decomposed multimedia gateway; Support of > ITU-T > > recommendation H.248 > > > > more details can be found at: <> > > > > Best regards > > > > Helmut Schink > > > > > -------------------------------------------------------------------------- > > -- > > ------------ > > Dr. Helmut Schink > > Siemens AG > > Information and Communication Networks > > Advanced Network Standards > > phone: +49 89 722 44523 > > mobile: +49 172 8146471 > > mailto:helmut.schink@icn.siemens.de > > http://intranet.icn.siemens.de/marketing/cs21/index.html (intranet > use > > only) > > http://www.siemens.de (publically accessible) > > <> > > New Work Items proposed at TIPHON#17 > > These WIs are now submitted to your approval*, please send your > comments to the TIPHON mailing list > To check the details of individual Work Items click on the "details > and Download" links on this page or download the work item sheets > here. > (*)The approval process will end on the 21st of April 2000 > > IDENTIFICATION TITLE STATUS > > 1 Deliverable Type: TR Requirements for Current Status: 0 > Ref. DTR/TIPHON-01006 the IP Transport Next Status: > Technical Body: TIPHON WG1 Plane TB adoption of WI (21-04-2000) > Details and Download (approval on mailing list) > > 2 Deliverable Type: MI Project Method Current Status: 0 > Ref. MI/TIPHON-01007 Definition Next Status: > Technical Body: TIPHON WG1 TB adoption of WI (21-04-2000) > Details and Download (approval on mailing list) > > 3 Deliverable Type: TR Requirements Current Status: 0 > Ref. DTR/TIPHON-01008 Definition Next Status: > Technical Body: TIPHON WG1 Study; TB adoption of WI (21-04-2000) > Details and Download Scope and (approval on mailing list) > requirements for > a simple call; > > 4 Deliverable Type: TS Release 3; Current Status: 0 > Ref. DTS/TIPHON-01009 Scope and Next Status: > Technical Body: TIPHON WG1 requirements for TB adoption of WI (21-04-2000) > Details and Download a simple call (approval on mailing list) > > 5 Deliverable Type: TS Release 3; Current Status: 0 > Ref. DTS/TIPHON-01010 Scope and Next Status: > Technical Body: TIPHON WG1 requirements for TB adoption of WI (21-04-2000) > Details and Download QoS management (approval on mailing list) > in TIPHON > systems > > 6 Deliverable Type: TS Release 3; Current Status: 0 > Ref. DTS/TIPHON-01011 Requirements for Next Status: > Technical Body: TIPHON WG1 Alarm Reporting TB adoption of WI (21-04-2000) > Details and Download in TIPHON (approval on mailing list) > systems > > 7 Deliverable Type: TS Protocol Current Status: 0 > Ref. DTS/TIPHON-03016 Framework Next Status: > Technical Body: TIPHON WG3 TB adoption of WI (21-04-2000) > Details and Download (approval on mailing list) > > 8 Doc. Nb. TS 101 329-2 Ver. 2.0.0 End to End Current Status: 0 > Ref. RTS/TIPHON-05012 Quality of Next Status: > Technical Body: TIPHON WG5 Service in TB adoption of WI (21-04-2000) > Details and Download TIPHON Systems (approval on mailing list) > Definition of > Quality of > Service (QoS) > Classes > > 9 Doc. Nb. TS 101 329-6 Ver. 2.0.0 End to End Current Status: 0 > Ref. RTS/TIPHON-05013 Quality of Next Status: > Technical Body: TIPHON WG5 Service in TB adoption of WI (21-04-2000) > Details and Download TIPHON Systems (approval on mailing list) > Actual > measurements of > network and > terminal > characteristics > and performance > parameters in > TIPHON networks > and their > influence on > voice quality > > 10 Deliverable Type: TS Conformance Test Current Status: 0 > Ref. DTS/TIPHON-06016 Specifications Next Status: > Technical Body: TIPHON WG6 for the support TB adoption of WI (21-04-2000) > Details and Download of packet based (approval on mailing list) > multimedia > communications > systems; > H225.0 Test > Suite Structure > and Test > Purposes > (TSS&TP) for > Terminal, > Gatekeeper and > Gateway > > 11 Deliverable Type: TS Protocol Current Status: 0 > Ref. DTS/TIPHON-06017 Implementation Next Status: > Technical Body: TIPHON WG6 Conformance TB adoption of WI (21-04-2000) > Details and Download Statement (PICS) (approval on mailing list) > proforma for the > support of > physically > decomposed > multimedia > gateway; > Support of ITU-T > recommendation > H.248 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 29 00:17:05 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04840 for ; Wed, 29 Mar 2000 00:17:05 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.55F410B0@standards.nortelnetworks.com>; Wed, 29 Mar 2000 0:11:31 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 108877 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Mar 2000 00:10:16 -0500 Received: from motgate.mot.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.28C41270@standards.nortelnetworks.com>; Wed, 29 Mar 2000 0:10:15 -0500 Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id WAA29879; Tue, 28 Mar 2000 22:15:06 -0700 (MST)] Received: [from relay2.cig.mot.com (relay2.cig.mot.com [136.182.15.24]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id WAA22601; Tue, 28 Mar 2000 22:15:05 -0700 (MST)] Received: from cig.mot.com (mvp0.corp.mot.com [129.188.147.10]) by relay2.cig.mot.com (8.9.0/SCERG-RELAY-1.11b) with ESMTP id XAA19968; Tue, 28 Mar 2000 23:15:02 -0600 (CST) X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38E1922D.B6212794@cig.mot.com> Date: Tue, 28 Mar 2000 23:18:37 -0600 Reply-To: Qiaobing Xie Sender: "Media Gateway Control (megaco)" From: Qiaobing Xie Subject: Re: Proposed ADELAIDE Agenda (revised) X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Tom, It is still a little unclear to me what MEGACO WG intends to do with those H.248 Annexes (determined by ITU). The one I am especially interested in is Annex H (using SCTP as the alternative transport). I and the other authors of that Annex has proposed to make it an informational RFC in IETF. Should this be mentioned at the meeting? regards, -Qiaobing Tom-PT Taylor wrote: > > Discussion here in Adelaide and review of activity on the list has suggested > that we need to spend less time on the base protocol document and more on > looking forward. To that end, here is a revised proposal for the meeting > agenda tomorrow morning. > > Broad outline: > > 09:00 - 09:05 Agenda bashing > 09:05 - 09:15 Status review (Taylor, Bilalis, Blatherwick?) > 09:15 - 09:45 Looking forward (detailed list of issues below) (Taylor) > 09:45 - 09:55 Interoperability plans (Rosen, Taylor) > 09:55 - 10:25 Current work > draft-ietf-megaco-ipphone-02.txt (Blatherwick) > draft-ietf-megaco-naspkg-00.txt (Taylor) > draft-ietf-megaco-R2package-00.txt (??) > draft-ietf-megaco-mib-00.txt (Holdrege, Brown) > 10:25-10:50 Potential future work > draft-brown-supplpkgs-00.txt (Brown) > draft-bouwen-megaco-isdn-00.txt (Van Doorselaer) > draft [ATM] > draft-ricagni-megaco-umts-all-ip-00.txt (Ricagni) > Other suggestions? > 10:50-11:30 Review of proposed corrections to base document (Taylor) > > Issues looking forward: > > (1) Base protocol evolution: > -- what process for IETF participation? > -- what does the IETF publish? > -- do we apply IETF process to take Megaco v1 to Draft Standard? > > (2) Packages: > -- what track? Decision on per-case basis? > -- what process for publishing ITU-generated packages? > -- what process for creating IETF-generated packages? > > (3) Profiles: > -- who creates? > -- registration process? > > Bottom line: does IETF wish to continue to participate in Megaco/H.248 > development? If so, should Megaco continue to exist, should offshoot WGs be > constituted as needed, or should everything be handled at the IESG level? > > Tom Taylor > Advisor -- Emerging Carrier IP Standards > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) > Phone and FAX: +1 613 736 0961 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 29 01:30:19 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08567 for ; Wed, 29 Mar 2000 01:30:19 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8F3B1B20@standards.nortelnetworks.com>; Wed, 29 Mar 2000 1:24:42 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 109023 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Mar 2000 01:23:03 -0500 Received: from auemlsrv.firewall.lucent.com (192.11.223.161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5438E7A0@standards.nortelnetworks.com>; Wed, 29 Mar 2000 1:23:03 -0500 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 BAA04615 for ; Wed, 29 Mar 2000 01:27:57 -0500 (EST) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id BAA04611 for ; Wed, 29 Mar 2000 01:27:56 -0500 (EST) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id IAA06234; Wed, 29 Mar 2000 08:27:44 +0200 (MET DST) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id IAA06226; Wed, 29 Mar 2000 08:27:43 +0200 (MET DST) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 References: <38DFC606.93C0AFC9@ficon-tech.com> <38E071BD.8FABF9D7@lucent.com> <38E0F651.D07A9577@ficon-tech.com> Content-Type: text/plain; charset=iso-8859-1 Message-ID: <38E1A24B.1A0CC259@lucent.com> Date: Wed, 29 Mar 2000 08:27:23 +0200 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: v16 comments: digit map To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA08567 Harpreet, Tom wrote most of the text on digit maps, so let's hope he can clear things up in between sessions in Adelaide. But if my understanding is correct, the start timer is started at the beginning of every digit map. Only its default value can be overridden, by using "T". Maybe overridden was not the right word. John Harpreet Singh Anand wrote: > > Hello John, > > John Segers wrote: > > > 1. The "T" timer is used to override the default start timer. > > My question was not on configuring the value of Start timer. The text in the > draft says "The Start timer is started at the beginning of every digit map > use, but can be > overridden.”. This means that MGC can configure whether MG should start the > start timer or not. My question was how to configure this. Is it by setting a > value of 0 ? > > Regards, > Harpreet -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 306 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 29 02:17:12 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16949 for ; Wed, 29 Mar 2000 02:17:12 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.25B75EF0@standards.nortelnetworks.com>; Wed, 29 Mar 2000 2:11:52 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 109142 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Mar 2000 02:10:21 -0500 Received: from ish7.ericsson.com.au (203.61.155.111) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.89585AB0@standards.nortelnetworks.com>; Wed, 29 Mar 2000 2:00:20 -0500 Received: from brsi02.epa.ericsson.se (brsi02 [146.11.15.8]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id RAA23546; Wed, 29 Mar 2000 17:03:36 +1000 (EST) Received: from mcsi00.epa.ericsson.se (mcsi00 [146.11.8.201]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id RAA19463; Wed, 29 Mar 2000 17:04:20 +1000 (EST) Received: from ericsson.com (7-137.epa.ericsson.se [146.11.7.137]) by mcsi00.epa.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id RAA09313; Wed, 29 Mar 2000 17:03:38 +1000 (EST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38E1AABA.A39BE02D@ericsson.com> Date: Wed, 29 Mar 2000 17:03:22 +1000 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Proposed ADELAIDE Agenda (revised) X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Tom, Can we discuss draft-ricagni-megaco-umts-all-ip-00.txt as it didn't make the submission deadline (it came on Monday) and its the first we've seen this topic? Cheers, Christian Tom-PT Taylor wrote: > > Discussion here in Adelaide and review of activity on the list has suggested > that we need to spend less time on the base protocol document and more on > looking forward. To that end, here is a revised proposal for the meeting > agenda tomorrow morning. > > Broad outline: > > 09:00 - 09:05 Agenda bashing > 09:05 - 09:15 Status review (Taylor, Bilalis, Blatherwick?) > 09:15 - 09:45 Looking forward (detailed list of issues below) (Taylor) > 09:45 - 09:55 Interoperability plans (Rosen, Taylor) > 09:55 - 10:25 Current work > draft-ietf-megaco-ipphone-02.txt (Blatherwick) > draft-ietf-megaco-naspkg-00.txt (Taylor) > draft-ietf-megaco-R2package-00.txt (??) > draft-ietf-megaco-mib-00.txt (Holdrege, Brown) > 10:25-10:50 Potential future work > draft-brown-supplpkgs-00.txt (Brown) > draft-bouwen-megaco-isdn-00.txt (Van Doorselaer) > draft [ATM] > draft-ricagni-megaco-umts-all-ip-00.txt (Ricagni) > Other suggestions? > 10:50-11:30 Review of proposed corrections to base document (Taylor) > > Issues looking forward: > > (1) Base protocol evolution: > -- what process for IETF participation? > -- what does the IETF publish? > -- do we apply IETF process to take Megaco v1 to Draft Standard? > > (2) Packages: > -- what track? Decision on per-case basis? > -- what process for publishing ITU-generated packages? > -- what process for creating IETF-generated packages? > > (3) Profiles: > -- who creates? > -- registration process? > > Bottom line: does IETF wish to continue to participate in Megaco/H.248 > development? If so, should Megaco continue to exist, should offshoot WGs be > constituted as needed, or should everything be handled at the IESG level? > > Tom Taylor > Advisor -- Emerging Carrier IP Standards > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) > Phone and FAX: +1 613 736 0961 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 29 02:40:20 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17151 for ; Wed, 29 Mar 2000 02:40:20 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5E008590@standards.nortelnetworks.com>; Wed, 29 Mar 2000 2:34:54 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 109176 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Mar 2000 02:32:55 -0500 Received: from penguin.wise.edt.ericsson.se (194.237.142.110) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.166BA1B0@standards.nortelnetworks.com>; Wed, 29 Mar 2000 2:32:54 -0500 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id JAA20887 for ; Wed, 29 Mar 2000 09:37:44 +0200 (MET DST) Received: from ericsson.com (aletx223.al.etx.ericsson.se [130.100.179.223]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id JAA24161 for ; Wed, 29 Mar 2000 09:37:40 +0200 (MET DST) X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF6780AD@whq-msgusr-02.fore.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38E1B2C2.F18CBB51@ericsson.com> Date: Wed, 29 Mar 2000 09:37:38 +0200 Reply-To: Stephen Terrill Sender: "Media Gateway Control (megaco)" From: Stephen Terrill Organization: L.M. Ericsson Subject: Re: DTMF detection To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, I support Brian in this as it is also very dependant on the media stream as well (e.g. the DTMF in PCM Codec speach for the STM bearer will require different handling that the RTP stream(s)). Regards, ..//Steve "Rosen, Brian" wrote: > I'm inclined to declare this issue out of scope of Megaco, as it > only deals with what happens in the media stream and has nothing > to do with the control of the streams or the connections. I > personally think that you would NOT substitute comfort noise in any > conditions. > > Determining support of an RTP payload capability in the MG is possible > with the standard Megaco audit capabilities mechanism. How two > MGCs determine whether the opposite MG can do it is an interMGC > protocol issue, and clearly out of scope of Megaco. > > Brian > > > -----Original Message----- > > From: Yu Zhu [mailto:Yu_Zhu@MW.3COM.COM] > > Sent: Tuesday, March 28, 2000 1:05 PM > > To: MEGACO@standards.nortelnetworks.com > > Subject: DTMF detection > > > > > > Hi there, > > > > The MG shall support detecting and passing DTMF signals to > > the peer gateway. The > > MG can use various methods in order to transport DTMF depending on its > > configuration and instructions by the MGC. > > The three different types of mechanisms for transport of DTMF are : > > 1). To the MGC through the standard MEGACO DTMF package > > 2) In-band in the RTP stream and > > 3) Out-of-band through a special payload type in the RTP > > stream (per the > > Internet-draft "RTP Payload for DTMF Digits, Telephony Tones > > and Telephony > > Signals") > > > > In case of sending the DTMF trough the MGC and also when > > sending it with special > > RTP payloads as defined in the latest IETF draft , Should the > > DTMF be extracted > > from the media stream and replaced with comfort noise ? If > > someone chooses to > > use the special RTP packets and extracts DTMF out of media > > stream, how is it > > determined that the other end supports the same mechanism ? > > > > Regards, > > -- Yu Zhu > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 29 04:19:52 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17925 for ; Wed, 29 Mar 2000 04:19:50 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.38CDEFC0@standards.nortelnetworks.com>; Wed, 29 Mar 2000 4:14:05 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 109300 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Mar 2000 04:12:32 -0500 Received: from relay.mail.pipex.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.01771100@standards.nortelnetworks.com>; Wed, 29 Mar 2000 4:12:32 -0500 Received: (qmail 10586 invoked from network); 29 Mar 2000 09:17:24 -0000 Received: from gatekeeper.sgcs.co.uk (HELO bevx03.gpt.co.uk) (194.129.217.113) by iprelay.mail.pipex.net with SMTP; 29 Mar 2000 09:17:24 -0000 Received: from CONVERSION-DAEMON by siemenscomms.co.uk (PMDF V5.1-12 #D3115) id <01JNLNXI2L4G90RXVX@siemenscomms.co.uk>; Wed, 29 Mar 2000 10:14:33 BST Received: from beex01.sgcs.co.uk ([19.0.53.101]) by siemenscomms.co.uk (PMDF V5.1-12 #D3115) with ESMTP id <01JNLNUUAH6O90S8J2@siemenscomms.co.uk>; Wed, 29 Mar 2000 10:11:08 +0100 (BST) Received: by beex01.sgcs.co.uk with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Mar 2000 10:10:54 +0100 Content-return: allowed MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Message-ID: <5AC7D3F55147D311AA1700A0C99583ED2C36BC@beex03.sgcs.co.uk> Date: Wed, 29 Mar 2000 10:10:52 +0100 Reply-To: "Drage, Keith" Sender: "Media Gateway Control (megaco)" Comments: *********************************************** Comments: * Our domain is now siemenscomms.co.uk * Comments: * Please update your address book accordingly * Comments: *********************************************** From: "Drage, Keith" Subject: Re: FW: new proposed TIPHON work items X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7BIT There seems to be a misconception in the last couple of messages on this thread as to what a PICS proforma is. This is defined in ISO 9646 and is a formal restatement of all the options within the underlying protocol standard, with check boxes that the implementor can tick. The proforma is filled in by the implementor to become a PICS. As such a PICS proforma can be created as soon as the underlying protocol text exists, it does not need to wait for an implementation. It also does not need to wait for the specification of either applications or packages, as those will be dealt with in separate documentation. While a completed PICS may provided a means of identifying whether two implementations of a standard will interoperate, i.e. in identifying whether compatible options have been selected, it is not in itself a test document. It may provide a means of specifying the input parameters for test case selection in a test document. If you want to know more about PICS proformas, apart from referring to ISO 9646, I suggest also a reading of ETSI EG 201 058 - freely available from the ETSI web site. ETSI TIPHON is apparently interested in providing conformance test documentation in the future, and ETSI has a well established reputation for such work on other protocols. Conformance testing connects the implementation to a tester, which then runs a test script, and excercises the implementation according to the requirements of the underlying protocol specification. It assesses whether those requirements have been implemented. It does not prove that an implementation will interwork with another implementation. For an overview of required documentation for conformance testing, I suggest reading ETSI ETS 300 406. Conformance testing is capable of assessing both normal behaviour and exceptional behaviour (e.g. error recovery). Interoperability testing only tests whether one implementation will interwork with another implementation. As such, it only provides a means of assessing the normal behaviour, unless some sort of exceptional behaviour is introduced into the operation of the peer implementation. As such, interoperability testing and conformance testing are complementary. The capability of providing either form of tests without specified applications and packages depends on the available points of control within the implementation. For conformance testing, these are specified in the ATS (abstract test suite), and therefore do not need to be understood at the time of writing the TSS&TP (test suite structure and test purpose). Keith Drage > --------------------------------------------------------------- > Keith Drage (keith.drage@siemenscomms.co.uk) > Siemens Communications Limited, > Technology Drive, Beeston, Nottingham NG9 1LA, UK > Tel: +44 115 943 4991 Fax: +44 115 943 4992 > --------------------------------------------------------------- > Internet communications are not secure and therefore Siemens > Communications Limited does not accept legal responsibility for the > contents of this message. Any views or opinions presented are solely > those of the author and do not necessarily represent those of Siemens > Communications Limited unless otherwise specifically stated. > > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > Sent: Wednesday, March 29, 2000 2:24 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: FW: new proposed TIPHON work items > > > G'Day Tom, > > I think going for the Tiphon PICS is a bit premature for a > first interop > test. Some people may not be interested in Tiphon GWs (I'm thinking of > you Pete :-)). > I'm sure this will come up in discussions in Adelaide. > > Cheers, Christian > > > Tom-PT Taylor wrote: > > > > Megaco followers may have an interest in this one, considering the > > recent > > discussions on interoperability testing. Is this a valid work item, > > is it > > premature, is it a necessary step? Comments? > > > > > -----Original Message----- > > > From: Schink Helmut [SMTP:Helmut.Schink@icn.siemens.de] > > > Sent: Thursday, March 23, 2000 7:40 AM > > > To: new-work@ietf.org > > > Cc: 'TIPHON_PMC' > > > Subject: new proposed TIPHON work items > > > > > > A series of new work items have been proposed at the TIPHON#17 > > meeting: > > > TIPHON has not made any determination as yet. The following titles > > have > > > submitted: > > > > > [[TomT]] ... > > > 11.Protocol Implementation Conformance Statement (PICS) proforma > > for the > > > support of physically decomposed multimedia gateway; Support of > > ITU-T > > > recommendation H.248 > > > > > > more details can be found at: <> > > > > > > Best regards > > > > > > Helmut Schink > > > > > > > > > -------------------------------------------------------------- > ------------ > > > -- > > > ------------ > > > Dr. Helmut Schink > > > Siemens AG > > > Information and Communication Networks > > > Advanced Network Standards > > > phone: +49 89 722 44523 > > > mobile: +49 172 8146471 > > > mailto:helmut.schink@icn.siemens.de > > > http://intranet.icn.siemens.de/marketing/cs21/index.html (intranet > > use > > > only) > > > http://www.siemens.de (publically accessible) > > > <> > > > > New Work Items proposed at TIPHON#17 > > > > These WIs are now submitted to your approval*, please send your > > comments to the TIPHON mailing list > > To check the details of individual Work Items click on the "details > > and Download" links on this page or download the work item sheets > > here. > > (*)The approval process will end on the 21st of April 2000 > > > > IDENTIFICATION TITLE > STATUS > > > > 1 Deliverable Type: TR Requirements for > Current Status: 0 > > Ref. DTR/TIPHON-01006 the IP Transport > Next Status: > > Technical Body: TIPHON WG1 Plane TB > adoption of WI (21-04-2000) > > Details and Download > (approval on mailing list) > > > > 2 Deliverable Type: MI Project Method > Current Status: 0 > > Ref. MI/TIPHON-01007 Definition > Next Status: > > Technical Body: TIPHON WG1 TB > adoption of WI (21-04-2000) > > Details and Download > (approval on mailing list) > > > > 3 Deliverable Type: TR Requirements > Current Status: 0 > > Ref. DTR/TIPHON-01008 Definition > Next Status: > > Technical Body: TIPHON WG1 Study; TB > adoption of WI (21-04-2000) > > Details and Download Scope and > (approval on mailing list) > > requirements for > > a simple call; > > > > 4 Deliverable Type: TS Release 3; > Current Status: 0 > > Ref. DTS/TIPHON-01009 Scope and > Next Status: > > Technical Body: TIPHON WG1 requirements for TB > adoption of WI (21-04-2000) > > Details and Download a simple call > (approval on mailing list) > > > > 5 Deliverable Type: TS Release 3; > Current Status: 0 > > Ref. DTS/TIPHON-01010 Scope and > Next Status: > > Technical Body: TIPHON WG1 requirements for TB > adoption of WI (21-04-2000) > > Details and Download QoS management > (approval on mailing list) > > in TIPHON > > systems > > > > 6 Deliverable Type: TS Release 3; > Current Status: 0 > > Ref. DTS/TIPHON-01011 Requirements for > Next Status: > > Technical Body: TIPHON WG1 Alarm Reporting TB > adoption of WI (21-04-2000) > > Details and Download in TIPHON > (approval on mailing list) > > systems > > > > 7 Deliverable Type: TS Protocol > Current Status: 0 > > Ref. DTS/TIPHON-03016 Framework > Next Status: > > Technical Body: TIPHON WG3 TB > adoption of WI (21-04-2000) > > Details and Download > (approval on mailing list) > > > > 8 Doc. Nb. TS 101 329-2 Ver. 2.0.0 End to End > Current Status: 0 > > Ref. RTS/TIPHON-05012 Quality of > Next Status: > > Technical Body: TIPHON WG5 Service in TB > adoption of WI (21-04-2000) > > Details and Download TIPHON Systems > (approval on mailing list) > > Definition of > > Quality of > > Service (QoS) > > Classes > > > > 9 Doc. Nb. TS 101 329-6 Ver. 2.0.0 End to End > Current Status: 0 > > Ref. RTS/TIPHON-05013 Quality of > Next Status: > > Technical Body: TIPHON WG5 Service in TB > adoption of WI (21-04-2000) > > Details and Download TIPHON Systems > (approval on mailing list) > > Actual > > measurements of > > network and > > terminal > > characteristics > > and performance > > parameters in > > TIPHON networks > > and their > > influence on > > voice quality > > > > 10 Deliverable Type: TS Conformance Test > Current Status: 0 > > Ref. DTS/TIPHON-06016 Specifications > Next Status: > > Technical Body: TIPHON WG6 for the support TB > adoption of WI (21-04-2000) > > Details and Download of packet based > (approval on mailing list) > > multimedia > > communications > > systems; > > H225.0 Test > > Suite Structure > > and Test > > Purposes > > (TSS&TP) for > > Terminal, > > Gatekeeper and > > Gateway > > > > 11 Deliverable Type: TS Protocol > Current Status: 0 > > Ref. DTS/TIPHON-06017 Implementation > Next Status: > > Technical Body: TIPHON WG6 Conformance TB > adoption of WI (21-04-2000) > > Details and Download Statement (PICS) > (approval on mailing list) > > proforma for the > > support of > > physically > > decomposed > > multimedia > > gateway; > > Support of ITU-T > > recommendation > > H.248 > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 29 06:55:09 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19546 for ; Wed, 29 Mar 2000 06:55:09 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.ED9FB680@standards.nortelnetworks.com>; Wed, 29 Mar 2000 6:49:28 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 109582 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Mar 2000 06:47:56 -0500 Received: from centauri.starcon.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.510C5BD0@standards.nortelnetworks.com>; Wed, 29 Mar 2000 6:37:56 -0500 Received: from dashaus.hothaus.com (g210-hothaus.att-g.starcon.com [216.13.167.210]) by centauri.starcon.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com for ; Wed, 29 Mar 2000 03:42:48 -0800 Received: by DASHAUS with Internet Mail Service (5.5.2448.0) id ; Wed, 29 Mar 2000 03:42:17 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Message-ID: <5713E3714F03D4118AB9009027D5B3A2013982@NT-RMNA-EXCH> Date: Wed, 29 Mar 2000 03:40:34 -0800 Reply-To: Bob Lukas Sender: "Media Gateway Control (megaco)" From: Bob Lukas Subject: Re: Proposed ADELAIDE Agenda (revised) To: MEGACO@STANDARDS.NORTELNETWORKS.COM draft-ricagni-megaco-umts-all-ip-00.txt does not appear to be available at any of the usual places, nor is it listed in the I-D search index. > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > Sent: Wednesday, March 29, 2000 4:33 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Proposed ADELAIDE Agenda (revised) > > > G'Day Tom, > > Can we discuss draft-ricagni-megaco-umts-all-ip-00.txt as it > didn't make > the submission deadline (it came on Monday) and its the first > we've seen > this topic? > > Cheers, Christian > > > Tom-PT Taylor wrote: > > > > Discussion here in Adelaide and review of activity on the > list has suggested > > that we need to spend less time on the base protocol > document and more on > > looking forward. To that end, here is a revised proposal > for the meeting > > agenda tomorrow morning. > > > > Broad outline: > > > > 09:00 - 09:05 Agenda bashing > > 09:05 - 09:15 Status review (Taylor, Bilalis, Blatherwick?) > > 09:15 - 09:45 Looking forward (detailed list of issues > below) (Taylor) > > 09:45 - 09:55 Interoperability plans (Rosen, Taylor) > > 09:55 - 10:25 Current work > > draft-ietf-megaco-ipphone-02.txt (Blatherwick) > > draft-ietf-megaco-naspkg-00.txt (Taylor) > > draft-ietf-megaco-R2package-00.txt (??) > > draft-ietf-megaco-mib-00.txt (Holdrege, Brown) > > 10:25-10:50 Potential future work > > draft-brown-supplpkgs-00.txt (Brown) > > draft-bouwen-megaco-isdn-00.txt (Van Doorselaer) > > draft [ATM] > > draft-ricagni-megaco-umts-all-ip-00.txt (Ricagni) > > Other suggestions? > > 10:50-11:30 Review of proposed corrections to base document > (Taylor) > > > > Issues looking forward: > > > > (1) Base protocol evolution: > > -- what process for IETF participation? > > -- what does the IETF publish? > > -- do we apply IETF process to take Megaco v1 to Draft Standard? > > > > (2) Packages: > > -- what track? Decision on per-case basis? > > -- what process for publishing ITU-generated packages? > > -- what process for creating IETF-generated packages? > > > > (3) Profiles: > > -- who creates? > > -- registration process? > > > > Bottom line: does IETF wish to continue to participate in > Megaco/H.248 > > development? If so, should Megaco continue to exist, > should offshoot WGs be > > constituted as needed, or should everything be handled at > the IESG level? > > > > Tom Taylor > > Advisor -- Emerging Carrier IP Standards > > E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) > > Phone and FAX: +1 613 736 0961 > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 29 07:41:12 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20325 for ; Wed, 29 Mar 2000 07:41:12 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.62D7BE10@standards.nortelnetworks.com>; Wed, 29 Mar 2000 7:35:41 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 109755 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Mar 2000 07:34:17 -0500 Received: from ficon-tech.com (12.10.198.190) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2F311610@standards.nortelnetworks.com>; Wed, 29 Mar 2000 7:34:15 -0500 Received: from ficon-tech.com (sphilip.india.ficon-tech.com [172.25.1.104]) by ficon-tech.com (8.9.3/8.8.7) with ESMTP id SAA20305 for ; Wed, 29 Mar 2000 18:02:38 +0530 (IST) (envelope-from sphilip@ficon-tech.com) X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <38E1F908.40EDF6@ficon-tech.com> Date: Wed, 29 Mar 2000 18:07:29 +0530 Reply-To: Shalini Philip Sender: "Media Gateway Control (megaco)" From: Shalini Philip Organization: Ficon Technology Subject: Questions on V16. To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hello all, I have a few questions on the V16 Draft of MEGACO. 1. How does an MGC know how many streams can be created on a termination? Is it from the packages supported by the termination? 2. Refer to Last paragraph of Sec 7.1.7. A new setting of Local Control Descriptor replaces the last setting.” Does this change the default value of ReserveGroup & ReserveValue also, i.e., if RG and RV are set true in one command, then in the subsequent command if RG and RV are not specified, then MG would take their value as TRUE or FALSE? 3. Refer to last paragraph of Sec 7.1.7. How can MG delete some information from an existing descriptor? All the properties in the descriptor would have some default values. 4. Section 7.1.8, pt (a) talks about the possibility of no previously specified value, in which case the descriptor is ignored in further processing of the command. How can there be “no previously specified value”? All the properties in Local and Remote Descriptor would have some default value. Thanks & Regards, Shalini Philip Ficon Technology E-Mail : mailto:sphilip@ficon-tech.com Web : http://www.ficon-tech.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 29 19:31:07 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26263 for ; Wed, 29 Mar 2000 19:31:06 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.8D372E30@standards.nortelnetworks.com>; Wed, 29 Mar 2000 19:25:33 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 110846 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Mar 2000 19:24:12 -0500 Received: from smtprtp1.ntcom.nortel.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5CED1EB0@standards.nortelnetworks.com>; Wed, 29 Mar 2000 19:24:12 -0500 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp1.ntcom.nortel.net; Wed, 29 Mar 2000 18:14:59 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Mar 2000 18:14:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF99D4.97B6CF80" Message-ID: Date: Wed, 29 Mar 2000 18:14:50 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Proposal: explain MEGACO protocol RFC status explicitly X-To: Pekka.Pessi@nokia.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_01BF99D4.97B6CF80 Content-Type: text/plain Other people have addressed the major content of this note. I just want to correct an incorrect impression you may have of the role of the ITU-T Implementor's Guide: it is strictly for clarification and reporting of errors, not for adding of new features. That said, I think your idea of including a reference to the possibility of an Implementor's Guide in the RFC is a good one. This also raises a process issue: we have to make sure the contents of the IG can be influenced by the IETF and are made available to it. > -----Original Message----- > From: Pekka Pessi [SMTP:Pekka.Pessi@NOKIA.COM] > Sent: Tuesday, March 21, 2000 8:35 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Proposal: explain MEGACO protocol RFC status explicitly > > Hello all, > [[TomT]] ... So, the finalized ITU-T specification > actually consists of a recommendation document together with an > Implementor's Guide correcting the errors and omissions in the > recommendation document. IG may contain major changes that are > incompatible with the published recommendation document. Also, > when > referring to a ITU-T specification, like H.323v2, people are > actually referring to the recommendation together with the > respective implementor's guide. > > The ITU-T process is (or at least should be) familiar to the > developers using ITU-T recommendations. However, in Internet > community people are expecting that the RFC is not just a snapshot > of an on-going work. They don't anticipate that there is a > companion > document possibly changing the base protocol in every turn. > > Proposal > > I propose that the MEGACO RFC should contain a paragraph > explaining > the status of the text, ie. that the protocol will be changed by > an > Implementors' Guide published soon. The MEGACO RFC should also > recommend that any reference to it must also be accompanied with a > note explaining the status of the RFC, and a reference to the > Implementors' Guide. > > Best regards, > Pekka Pesi ------_=_NextPart_001_01BF99D4.97B6CF80 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Proposal: explain MEGACO protocol RFC status = explicitly

Other people have = addressed the major content of this note.  I just want to correct = an incorrect impression you may have of the role of the ITU-T = Implementor's Guide: it is strictly for clarification and reporting of = errors, not for adding of new features.

That said, I think = your idea of including a reference to the possibility of an = Implementor's Guide in the RFC is a good one.  This also raises a = process issue: we have to make sure the contents of the IG can be = influenced by the IETF and are made available to it.

    -----Original Message-----
    From:   Pekka Pessi [SMTP:Pekka.Pessi@NOKIA.COM]
    Sent:   Tuesday, March 21, 2000 8:35 AM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:       = Proposal: explain MEGACO protocol = RFC status explicitly

            Hello = all,

    [[TomT]]  ...
            So, the finalized ITU-T specification
            actually = consists of a recommendation document together with an
            Implementor's = Guide correcting the errors and omissions in the
            = recommendation document. IG may contain major changes that are
            incompatible = with the published recommendation document.  Also, when
            referring to = a ITU-T specification, like H.323v2, people are
            actually = referring to the recommendation together with the
            respective = implementor's guide.

            The ITU-T = process is (or at least should be) familiar to the
            developers = using ITU-T recommendations. However, in Internet
            community = people are expecting that the RFC is not just a snapshot
            of an = on-going work. They don't anticipate that there is a companion
            document = possibly changing the base protocol in every turn.

    Proposal

            I propose = that the MEGACO RFC should contain a paragraph explaining
            the status of = the text, ie. that the protocol will be changed by an
            Implementors' = Guide published soon. The MEGACO RFC should also
            recommend = that any reference to it must also be accompanied with a
            note = explaining the status of the RFC, and a reference to the
            Implementors' = Guide.

            Best = regards,
             &nb= sp;           &nb= sp;           &nb= sp;      Pekka Pesi

------_=_NextPart_001_01BF99D4.97B6CF80-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 29 22:28:36 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28739 for ; Wed, 29 Mar 2000 22:28:36 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.5B834C20@standards.nortelnetworks.com>; Wed, 29 Mar 2000 22:23:07 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 111175 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Mar 2000 22:21:39 -0500 Received: from dgesmtp01.wcom.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C12E6FC0@standards.nortelnetworks.com>; Wed, 29 Mar 2000 22:11:38 -0500 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0FS700B9AT3IZ3@firewall.mcit.com> for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 30 Mar 2000 03:16:30 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0FS700G01T3IES@pmismtp02.wcomnet.com>; Thu, 30 Mar 2000 03:16:30 +0000 (GMT) Received: from omzmta03.mcit.com ([166.37.214.9]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with ESMTP id <0FS700DGLT3HNE@pmismtp02.wcomnet.com>; Thu, 30 Mar 2000 03:16:30 +0000 (GMT) Received: from C25776A ([166.44.57.203]) by omzmta03.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000330031627.HJCU14422@C25776A>; Thu, 30 Mar 2000 03:16:27 +0000 MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: multipart/alternative; boundary="Boundary_(ID_LIt5ejNZqzb5id+LjI50hw)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Message-ID: Date: Wed, 29 Mar 2000 21:16:28 -0600 Reply-To: henry.sinnreich@wcom.com Sender: "Media Gateway Control (megaco)" From: Henry Sinnreich Subject: Re: Proposal: explain MEGACO protocol RFC status explicitly X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: This is a multi-part message in MIME format. --Boundary_(ID_LIt5ejNZqzb5id+LjI50hw) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit RE: Proposal: explain MEGACO protocol RFC status explicitlyI hope we don't portray an ITU implementer's guide on how to implement Internet technologies. Why do you keep pushing ITU concepts in an IETF WG? Right or wrong, we have different network philosophies and the intellectual competition is good. Intellectual 'harmonization' is bad IMHO. Henry -----Original Message----- From: Media Gateway Control (megaco) [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Tom-PT Taylor Sent: Wednesday, March 29, 2000 5:15 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Proposal: explain MEGACO protocol RFC status explicitly Other people have addressed the major content of this note. I just want to correct an incorrect impression you may have of the role of the ITU-T Implementor's Guide: it is strictly for clarification and reporting of errors, not for adding of new features. That said, I think your idea of including a reference to the possibility of an Implementor's Guide in the RFC is a good one. This also raises a process issue: we have to make sure the contents of the IG can be influenced by the IETF and are made available to it. -----Original Message----- From: Pekka Pessi [SMTP:Pekka.Pessi@NOKIA.COM] Sent: Tuesday, March 21, 2000 8:35 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Proposal: explain MEGACO protocol RFC status explicitly Hello all, [[TomT]] ... So, the finalized ITU-T specification actually consists of a recommendation document together with an Implementor's Guide correcting the errors and omissions in the recommendation document. IG may contain major changes that are incompatible with the published recommendation document. Also, when referring to a ITU-T specification, like H.323v2, people are actually referring to the recommendation together with the respective implementor's guide. The ITU-T process is (or at least should be) familiar to the developers using ITU-T recommendations. However, in Internet community people are expecting that the RFC is not just a snapshot of an on-going work. They don't anticipate that there is a companion document possibly changing the base protocol in every turn. Proposal I propose that the MEGACO RFC should contain a paragraph explaining the status of the text, ie. that the protocol will be changed by an Implementors' Guide published soon. The MEGACO RFC should also recommend that any reference to it must also be accompanied with a note explaining the status of the RFC, and a reference to the Implementors' Guide. Best regards, Pekka Pesi --Boundary_(ID_LIt5ejNZqzb5id+LjI50hw) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable RE: Proposal: explain MEGACO protocol RFC status = explicitly
I hope=20 we don't portray an ITU implementer's guide on how to implement Internet = technologies. Why do you keep pushing ITU concepts in an IETF=20 WG?
 
Right=20 or wrong, we have different network philosophies and the intellectual=20 competition is good. Intellectual 'harmonization' is bad=20 IMHO.
 
Henry
-----Original Message-----
From: Media Gateway = Control=20 (megaco) [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of=20 Tom-PT Taylor
Sent: Wednesday, March 29, 2000 5:15=20 PM
To: = MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re:=20 Proposal: explain MEGACO protocol RFC status = explicitly

Other people have = addressed the major=20 content of this note.  I just want to correct an incorrect = impression you=20 may have of the role of the ITU-T Implementor's Guide: it is strictly = for=20 clarification and reporting of errors, not for adding of new=20 features.

That said, I think your = idea of=20 including a reference to the possibility of an Implementor's Guide in = the RFC=20 is a good one.  This also raises a process issue: we have to make = sure=20 the contents of the IG can be influenced by the IETF and are made = available to=20 it.

    -----Original Message----- =
    From:       Pekka=20 Pessi [SMTP:Pekka.Pessi@NOKIA.COM]
    Sent:   Tuesday, March=20 21, 2000 8:35 AM
    To:     MEGACO@STANDARDS.NORTELNETWORKS.COM
    Subject:        = Proposal: explain MEGACO protocol RFC status=20 explicitly

            Hello=20 all,

    [[TomT]]  ...
           =20 So, the finalized ITU-T specification
            actually = consists of a=20 recommendation document together with an
            Implementor's = Guide=20 correcting the errors and omissions in the
            recommendation = document.=20 IG may contain major changes that are
            incompatible = with the=20 published recommendation document.  Also, when
            = referring to a=20 ITU-T specification, like H.323v2, people are
            actually = referring to the=20 recommendation together with the
            respective = implementor's=20 guide.

            The=20 ITU-T process is (or at least should be) familiar to the =
            = developers=20 using ITU-T recommendations. However, in Internet
            = community=20 people are expecting that the RFC is not just a snapshot     =
            of = an on-going=20 work. They don't anticipate that there is a companion     =
            = document=20 possibly changing the base protocol in every turn.

    Proposal

            I=20 propose that the MEGACO RFC should contain a paragraph = explaining=20
            the=20 status of the text, ie. that the protocol will be changed by = an=20
           =20 Implementors' Guide published soon. The MEGACO RFC should = also=20
           =20 recommend that any reference to it must also be accompanied with = a=20
            note=20 explaining the status of the RFC, and a reference to the =
            = Implementors'=20 Guide.

            Best=20 regards,
              &nbs= p;            = ;            =     =20 Pekka Pesi

--Boundary_(ID_LIt5ejNZqzb5id+LjI50hw)-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Mar 29 22:45:56 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29805 for ; Wed, 29 Mar 2000 22:45:56 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.9AE23820@standards.nortelnetworks.com>; Wed, 29 Mar 2000 22:39:12 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 111224 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 29 Mar 2000 22:37:57 -0500 Received: from PMESMTP02.wcom.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0752C1C0@standards.nortelnetworks.com>; Wed, 29 Mar 2000 22:27:55 -0500 Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FS700E6FTUOLR@firewall.mcit.com>; Thu, 30 Mar 2000 03:32:48 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0FS700J01TUNN6@dgismtp02.wcomnet.com>; Thu, 30 Mar 2000 03:32:48 +0000 (GMT) Received: from omzmta03.mcit.com ([166.37.214.9]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0FS700I4UTUNX7@dgismtp02.wcomnet.com>; Thu, 30 Mar 2000 03:32:47 +0000 (GMT) Received: from C25776A ([166.44.57.203]) by omzmta03.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000330033246.HKDJ14422@C25776A>; Thu, 30 Mar 2000 03:32:46 +0000 MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.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: Date: Wed, 29 Mar 2000 21:32:44 -0600 Reply-To: henry.sinnreich@wcom.com Sender: "Media Gateway Control (megaco)" From: Henry Sinnreich Subject: Re: Appeal to SIGTRAN WG Chair X-To: brian.bidulock@inet.com, SIGTRAN@STANDARDS.NORTELNETWORKS.COM X-cc: Brian E Carpenter , Steve Deering , Henning Schulzrinne , Scott Bradner , jh@telia.fi To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <38E2AA8E.D2E44562@inet.com> Content-Transfer-Encoding: 7bit My problem with Sigtran is less with the possible bugs, but with the model of promoting old circuit switched models and SS7, etc. on the Internet. It degrades IP to a cheap wire and keeps all the telco control and signaling in place. This applies equally to MEGACO. The usual argument that some people want to have a quick fix for "VoIP" does not justify messing around with the Internet architecture and getting even a stamp of approval for it from the IETF. This topic deserves a similar discussion as we had today in the Wireless BOF, and in the 47th IETF plenary. Glad to provide details and arguments. I do not speak for my company, but IMHO only, this is not desirable work in the IETF. Now let the flames roar... Henry From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 30 00:26:16 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01477 for ; Thu, 30 Mar 2000 00:26:16 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C1E58590@standards.nortelnetworks.com>; Thu, 30 Mar 2000 0:20:30 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 111469 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 30 Mar 2000 00:20:24 -0500 Received: from smtprch1.nortel.com (192.135.215.14) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.BDB48610@standards.nortelnetworks.com>; Thu, 30 Mar 2000 0:20:23 -0500 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Wed, 29 Mar 2000 23:09:44 -0600 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Mar 2000 23:09:19 -0600 X-Mailer: Internet Mail Service (5.5.2650.21) Message-ID: Date: Wed, 29 Mar 2000 23:09:16 -0600 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Summary of Issues Raised On the List To: MEGACO@STANDARDS.NORTELNETWORKS.COM Attached please find a summary of the issues raised on the list. The contents should be self-evident. Please pay special attention to section 4: we MUST close off on these issues within the next week so we can end Last Call in timely fashion. <> Tom Taylor Advisor -- Emerging Carrier IP Standards E-mail: taylor@nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961 begin 600 errata.txt M#0I-961I82!'871E=V%Y($-O;G1R;VP@("`@("`@("`@("`@("`@("`@("`@ M("`@("`@("`@("`@("`@("!0+E0N(%1A>6QO<@T*26YT97)N970@1')A9G0@ M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("!.;W)T M96P@3F5T=V]R:W,-"D1O8W5M96YT.B!D3H@4W1A;F1A2!O=&AE M<@T*("`@9&]C=6UE;G1S(&%T(&%N>2!T:6UE+B!)="!I6QO M2X-"@T*#0H-"@T*#0H-"E1A>6QO2`@(#0V,2TT-C<- M"B`@("`@("`@("`@("`@;W(@5')A;G-A8W1I;VY096YD:6YG+"!L97-T#0H@ M("`@("`@("`@("`@('1H97D@8W)E871E(')E'!I2!N;W0@:&%V92!R96-E:79E9`T*("`@("`@("`@("`@("!42!T:&5R969O2!S96-T:6]N('=H:6-H('=I;&P@2!R97%U:7)E+@T*#0H-"B`@(%-E M8W1I;VX@("`@27-S=64@("`@("`@("`@("`@("`@("`@("`@("`@("!297-O M;'5T:6]N#0H-"@T*("`@,B`@("`@("`@("!1+C6QO2!O9B!A('!H M>7-I8V%L#0H@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@ M("`@("`@("`@5&5R;6EN871I;VX@8V%N(&)E#0H@("`@("`@("`@("`@("`@ M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@8VAA;F=E9"!B>2!S971T M:6YG(&ET('1O#0H@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@ M("`@("`@("`@("`@82!D:69F97)E;G0@=F%L=64@=VAE;@T*("`@("`@("`@ M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@('1H92!497)M M:6YA=&EO;B!I'0N(@T*("`@-BXR+C0@ M("`@("!$:6=I=$UA<"!E;G1R>2!I;B!T86)L92!M86ME&ES=&EN9R!T97AT('1O#0H@("`@("`@("`@("`@(&5X<&QI8VET(')E9F5R M96YC92!T;R!$5$U&("`@("`@;F5W(&]N92!A0T*("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@ M("`@($IO:&X@4V5G97)S("@B1&5S8W)I<'1O<@T*("`@("`@("`@("`@("`@ M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@('!R;V-E'0-"B`@("`@("`@("`@("`@=7-E0T*("`@("`@ M("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@("`@(&5I=&AE M&ES=&EN9R!L;V=I8R!M87D@2!M871C:&5D(@T*("`@("`@("`@("`@ M("!F;W(@9&EG:70@;6%P(&-O;7!L971I;VX@=VAE;B`@('1O('1H92!E>&ES M=&EN9R!S96YT96YC90T*("`@("`@("`@("`@("!S:6YG;&4@8V%N9&ED871E M(')E;6%I;G,N#0H-"@T*("`@-RXQ+C$X("`@("!4:&ER9"!B=6QL970@871T M86-H960@=&\@("`@("`@($1E;&5T92!T:&4@8VQA=7-E("([#0H@("`@("`@ M("`@("`@('1H:7)D('!A7,@;&]O<&)A8VL@("`@("`@;&]O<&)A M8VMS(&%R92!C'0Z#0H@("`@("`@("`@("`@($%U9&ET M5F%L=64@9F]R("`@("`@("`@("`@("`@("`@(D5V96YT0G5F9F5R(')E='5R M;G,@=&AE#0H@("`@("`@("`@("`@($5V96YT0G5F9F5R1&5S8W)I<'1O'0@86YD M($%33BXQ(&%L;&]W(')E='5R;B`@("`@1FEX('!R;V1U8W1I;VX-"B`@($(N M,B`@("`@("`@;V8@6QO'0Z#0H@("`@("`@("`@("`@($5V96YT0G5F9F5R M1&5S8W)I<'1O'0@=&\@=&AE#0H@("`@("`@("`@ M("`@(%-E"!%6QO"!F;W(@<&%R;59A;'5E(&%N M9`T*("`@("`@("`@("`@("!604Q512!T;V=E=&AE6YT87@@9F]R#0H@("`@("`@("`@ M("`@(&1I9VET36%P1&5S8W)I<'1O2!T:&%T('9A;'5E2!) M12!R871H97(@=&AA;B!,;W<@("!T:&]S92!V86QI9"!F;W(@0F5A65R($-O;7!A=&EB:6QI='D@244@:7,@("`@("`@ M0V%P86)I;&ET>2!)10T*("`@("`@("`@("`@("!B96EN9R!U'!I M&5C=71E9"XB#0H@("`@("`@("`@("`@(&)E8V%U7,@8F4@("`@("!R96%D(&%S(&9O;&QO=W,Z(")4:&4@34<-"B`@("`@ M("`@("`@("`@(D1I"`@("`@("!3=&5P(#(P(&9A:6QS('1O('-H;W<@82`@("`@("`@ M($%D9"!T:&4@9F]L;&]W:6YG('1O('1H90T*("`@02XQ+C(@("`@("!R971U M'0-"B`@(%LS72!21D,@,C$Q.0T*#0H-"C@N($%C:VYO=VQE M9&=M96YT6QO<@T*("`@3F]R=&5L($YE='=O"`S-3$Q+"!3=&%T:6]N($,-"B`@($]T=&%W82P@3VYT87)I;RP@0V%N M861A($LQ62`T4#<-"B`@(%!H;VYE.B`K,2`V,3,@-S,V(#`Y-C$-"B`@($5M M86EL.B!T87EL;W)`;F]R=&5L;F5T=V]R:W,N8V]M#0H-"@T*#0H-"@T*#0H- M"@T*#0H-"@T*#0H-"@T*5&%Y;&]R("`@("`@("`@("!3=&%N9&%R9',@5')A M8VL@+2T@17AP:7)E2!N;W0@8F4@ M;6]D:69I960@:6X@86YY('=A>2P@2!R96UO=FEN9PT*("`@ M=&AE(&-O<'ER:6=H="!N;W1I8V4@;W(@2!OF%T M:6]N'!I; Thu, 30 Mar 2000 04:04:52 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.0103D560@standards.nortelnetworks.com>; Thu, 30 Mar 2000 3:57:01 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 111834 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 30 Mar 2000 03:55:38 -0500 Received: from lohi.eng.telia.fi by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6970B110@standards.nortelnetworks.com>; Thu, 30 Mar 2000 3:45:37 -0500 Received: (from jh@localhost) by lohi.eng.telia.fi (8.9.3/8.9.3/Debian 8.9.3-6) id LAA27097; Thu, 30 Mar 2000 11:46:17 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <38E2AA8E.D2E44562@inet.com> X-Mailer: VM 6.75 under Emacs 19.34.1 Message-ID: <14563.5208.966308.837706@lohi.eng.telia.fi> Date: Thu, 30 Mar 2000 11:46:16 +0300 Reply-To: Juha Heinanen Sender: "Media Gateway Control (megaco)" From: Juha Heinanen Subject: Re: Appeal to SIGTRAN WG Chair X-To: henry.sinnreich@wcom.com X-cc: brian.bidulock@inet.com, SIGTRAN@STANDARDS.NORTELNETWORKS.COM, Brian E Carpenter , Steve Deering , Henning Schulzrinne , Scott Bradner To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: Content-Transfer-Encoding: 7bit henry, i'm not a sigtran expert, but i see sigtran important in order to be able to place the signaling gateway anywhere on the internet. correct me if i'm wrong, but without sigtran, i would need to integrate the signaling gw with the media gw or connect the signaling gw directly to telephone switch using a separate physical interface. so i see sigtran simply as a way to tunnel itu signaling over the internet to a properly placed signaling gw, which then turns itu signaling to sip and/or mgcp. -- juha From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 30 05:45:21 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15265 for ; Thu, 30 Mar 2000 05:45:21 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.25347AD0@standards.nortelnetworks.com>; Thu, 30 Mar 2000 5:38:15 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 112007 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 30 Mar 2000 05:36:38 -0500 Received: from mail-gw.hursley.ibm.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.852C92D0@standards.nortelnetworks.com>; Thu, 30 Mar 2000 5:26:37 -0500 Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id LAA20000; Thu, 30 Mar 2000 11:27:15 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id LAA25772; Thu, 30 Mar 2000 11:26:57 +0100 (BST) X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <38E32C07.7AA0BE5C@hursley.ibm.com> Date: Thu, 30 Mar 2000 04:27:19 -0600 Reply-To: Brian E Carpenter Sender: "Media Gateway Control (megaco)" From: Brian E Carpenter Organization: IBM Subject: Re: Appeal to SIGTRAN WG Chair X-To: henry.sinnreich@wcom.com X-cc: brian.bidulock@inet.com, SIGTRAN@STANDARDS.NORTELNETWORKS.COM, Steve Deering , Henning Schulzrinne , Scott Bradner , jh@telia.fi, "John Klensin (IAB)" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Henry, I think I need to divert this to the new IAB chair... Henry Sinnreich wrote: > > My problem with Sigtran is less with the possible bugs, but with > the model of promoting old circuit switched models and SS7, etc. > on the Internet. It degrades IP to a cheap wire and keeps all > the telco control and signaling in place. > > This applies equally to MEGACO. > > The usual argument that some people want to have a quick fix for > "VoIP" does not justify messing around with the Internet > architecture and getting even a stamp of approval for it from > the IETF. > > This topic deserves a similar discussion as we had today in the > Wireless BOF, and in the 47th IETF plenary. Glad to provide > details and arguments. > > I do not speak for my company, but IMHO only, this is not > desirable work in the IETF. Now let the flames roar... > > Henry -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 30 07:17:08 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15929 for ; Thu, 30 Mar 2000 07:17:07 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.2AAB54E0@standards.nortelnetworks.com>; Thu, 30 Mar 2000 7:11:28 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 112165 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 30 Mar 2000 07:10:26 -0500 Received: from mail.axestech.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.A01FC2D0@standards.nortelnetworks.com>; Thu, 30 Mar 2000 7:00:26 -0500 Received: by maxip18.maxipro.com with Internet Mail Service (5.5.1960.3) id ; Thu, 30 Mar 2000 06:25:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.1960.3) Content-Type: text/plain Message-ID: Date: Thu, 30 Mar 2000 06:25:19 -0600 Reply-To: J Ramachandra Sender: "Media Gateway Control (megaco)" From: J Ramachandra Subject: Interim AH in MEGACO To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hello, I have a couple of questions on Interim AH Scheme. The MEGACO V16 document (section 10.2) refers to RFC 2402 Section 5. This in turn refers to RFC 2403 (HMAC-MD5-96) and RFC 2404 (HMAC-SHA-1-96)as two possible options. These two algorithms produce 128 and 160 bits authenticator value, but over the network only truncated 96 bits are transmitted to reduce the attack. Now, the question is, MEGACO/H.248 ABNF specifies authData as 32 to 64 Hex digits. Why is it not from 24 to 64 hex digits? Where one has to fit in the 24 hex digits(96 bits) in this 32 Hex digit space? OR am I missing something? Also, the same section specifies "synthesized IP header consisting of a 32 bit source IP address, a 32 bit destination address and an 16 bit UDP encoded as 10 hex digits". Which UDP port number to be used (Source or destination)? - J.K.Ramachandra, AXES TECHNOLOGIES. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Mar 30 17:42:38 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22826 for ; Thu, 30 Mar 2000 17:42:37 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.748422C0@standards.nortelnetworks.com>; Thu, 30 Mar 2000 17:36:18 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 112750 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 30 Mar 2000 17:34:22 -0500 Received: from PMESMTP02.wcom.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.C9301420@standards.nortelnetworks.com>; Thu, 30 Mar 2000 17:24:21 -0500 Received: from dgismtp02.wcomnet.com ([166.38.58.142]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0FS900BEPAGSXI@firewall.mcit.com>; Thu, 30 Mar 2000 22:29:16 +0000 (GMT) Received: from dgismtp02.wcomnet.com by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0FS900D01AGRNZ@dgismtp02.wcomnet.com>; Thu, 30 Mar 2000 22:29:15 +0000 (GMT) Received: from omzmta02.mcit.com ([166.37.214.8]) by dgismtp02.wcomnet.com (PMDF V5.2-33 #42263) with ESMTP id <0FS900D09AGQMO@dgismtp02.wcomnet.com>; Thu, 30 Mar 2000 22:29:15 +0000 (GMT) Received: from C25776A ([166.44.56.171]) by omzmta02.mcit.com (InterMail v03.02.05 118 120) with SMTP id <20000330222913.FKKD19113@[166.44.56.171]>; Thu, 30 Mar 2000 22:29:13 +0000 MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.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: Date: Thu, 30 Mar 2000 16:29:12 -0600 Reply-To: henry.sinnreich@wcom.com Sender: "Media Gateway Control (megaco)" From: Henry Sinnreich Subject: Re: Appeal to SIGTRAN WG Chair X-To: Juha Heinanen X-cc: brian.bidulock@inet.com, SIGTRAN@STANDARDS.NORTELNETWORKS.COM, Brian E Carpenter , Steve Deering , Henning Schulzrinne , Scott Bradner To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <14563.5208.966308.837706@lohi.eng.telia.fi> Content-Transfer-Encoding: 7bit Juha, >so i see sigtran simply as a way to tunnel itu >signaling over the >internet to a properly placed signaling gw, which then >turns itu >signaling to sip and/or mgcp. Yes, as I hinted, it is not the technology developed by the WG that I objected, or possible bugs (would be normal at the beginning)), but the agenda to use IP as a cheap wire, to keep telco signaling and "IN" control in place. Fortunately, the Sigtran WG did a good job and developed a quite promising SCTP that may be put to better use for various applications. Henry >-----Original Message----- >From: Juha Heinanen [mailto:jh@lohi.eng.telia.fi] >Sent: Thursday, March 30, 2000 2:46 AM >To: henry.sinnreich@wcom.com >Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM; >brian.bidulock@inet.com; >SIGTRAN@STANDARDS.NORTELNETWORKS.COM; Brian E >Carpenter; Steve Deering; >Henning Schulzrinne; Scott Bradner >Subject: RE: Appeal to SIGTRAN WG Chair > > >henry, > >i'm not a sigtran expert, but i see sigtran important >in order to be >able to place the signaling gateway anywhere on the >internet. correct >me if i'm wrong, but without sigtran, i would need to >integrate the >signaling gw with the media gw or connect the >signaling gw directly to >telephone switch using a separate physical interface. > >so i see sigtran simply as a way to tunnel itu >signaling over the >internet to a properly placed signaling gw, which then >turns itu >signaling to sip and/or mgcp. > >-- juha From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 31 09:37:58 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14100 for ; Fri, 31 Mar 2000 09:37:58 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.08D640E0@standards.nortelnetworks.com>; Fri, 31 Mar 2000 9:32:30 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 113605 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 31 Mar 2000 09:30:55 -0500 Received: from rmx13.mail.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.6A981C60@standards.nortelnetworks.com>; Fri, 31 Mar 2000 9:20:55 -0500 Received: from webb2.iname.net (webb2.iname.net [165.251.4.132]) by rmx13.mail.com (8.9.1/8.9.3) with ESMTP id JAA16343 for ; Fri, 31 Mar 2000 09:25:55 -0500 (EST) Received: (from root@localhost) by webb2.iname.net (8.9.1a/8.9.2.Alpha2) id JAA16477; Fri, 31 Mar 2000 09:25:55 -0500 (EST) MIME-Version: 1.0 Content-Type: Text/Plain Content-Transfer-Encoding: 7bit Message-ID: <000331092554FY.19516@webb2.iname.net> Date: Fri, 31 Mar 2000 09:25:54 -0500 Reply-To: i-appliance@TECHNOLOGIST.COM Sender: "Media Gateway Control (megaco)" From: i-appliance@TECHNOLOGIST.COM Subject: Fwd: Re: new ID draft-sijben-megaco-cool-profile-00.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit It seems like the IETF Secretariat is too busy at the meeting to turn their autoresponder off. So we are sending this to the list directly and try the secretariat again later. We from I-@ppliance (http://www.bigfoot.com/~i-appliance) would like offer the follwing profile & package to the MEGACO community. From the abstract: This draft addresses two domestic needs and proposes solution to improve the life of many people using publicly available Internet technology. It may be the first of a series of such drafts aimed at addressing more of such needs. The draft specifies a profile of the megaco protocol for use with refrigerators. The draft itself can be found at: http://members.tripod.lycos.nl/sijben/i-appliance/draft-sijben-megaco-cool-profile-00.txt ---- you wrote: > Greetings, > > We are sorry, but the cut-off for Internet-Draft submissions was Friday, > March 10 at 5pm ET. Your submission will not be retained (i.e. you > need to resubmit) after March 7th. > > Any submissions received prior to March 26, 2000 will not be retained; > they must be resubmitted. Internet-Draft submissions received on or after > March 27 will be processed. However, Internet-Draft announcements will > not be sent until after the meeting concludes. > > If you receive this announcement, your submission will NOT be processed. > > Thank you for your understanding. > > > IETF Secretariat > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Mar 31 10:57:11 2000 Received: from standards.nortelnetworks.com (standards.nortelnetworks.com [137.118.21.16]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14981 for ; Fri, 31 Mar 2000 10:57:11 -0500 (EST) Received: from standards (137.118.21.16) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.16C10630@standards.nortelnetworks.com>; Fri, 31 Mar 2000 10:51:37 -0500 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 113697 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 31 Mar 2000 10:50:03 -0500 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1a) with SMTP id <0.DE2376A0@standards.nortelnetworks.com>; Fri, 31 Mar 2000 10:50:02 -0500 Received: from chsharp-tecra.cisco.com (chsharp-isdn.cisco.com [171.68.116.221]) by mailman.cisco.com (8.8.8+Sun/CISCO.SERVER.1.2) with ESMTP id HAA27379; Fri, 31 Mar 2000 07:54:57 -0800 (PST) X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.3.1.2.20000331100603.00b897d0@dogwood.cisco.com> Date: Fri, 31 Mar 2000 10:26:50 -0500 Reply-To: Chip Sharp Sender: "Media Gateway Control (megaco)" From: Chip Sharp Subject: Re: Fwd: Re: new ID draft-sijben-megaco-cool-profile-00.txt X-To: i-appliance@TECHNOLOGIST.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <000331092554FY.19516@webb2.iname.net> If all you want is status of the refrigerator door, then you could just use SNMP with a Refrigerator MIB. Of course, I'd want to know a few more things and might want RMON. For example, I might want to get a trap if the temperature gets too low or too high. Either way, considering the use of binary encoding, you might require the refrigerator to implement ASN.1 (with BER) which might put too much processing power burden on the refrigerator. Perhaps we need a new protocol. The Simple Refrigerator Control Protocol (SRCP). It could be a cooperative process between the IETF Megaco WG and the Commercial Refrigerator Manufacturers Association (CRMA) (http://www.arcat.com/arcatcos/cos07/arc07863.cfm) Of course we would need a formal MOU negotiated between Tom and CRMA and signed by Scott to make sure we have the SRCP standardization process in place before we start. ;-), ;-), ;-) At 09:25 AM 3/31/00 -0500, i-appliance@TECHNOLOGIST.COM wrote: >It seems like the IETF Secretariat is too busy at the meeting to turn >their autoresponder off. > >So we are sending this to the list directly and try the secretariat again >later. > >We from I-@ppliance (http://www.bigfoot.com/~i-appliance) would like offer >the follwing profile & package to the MEGACO community. > > >From the abstract: > This draft addresses two domestic needs and proposes > solution to improve the life of many people using > publicly available Internet technology. It may be > the first of a series of such drafts aimed at > addressing more of such needs. > > The draft specifies a profile of the megaco protocol > for use with refrigerators. > >The draft itself can be found at: > >http://members.tripod.lycos.nl/sijben/i-appliance/draft-sijben-megaco-cool-profile-00.txt > > > > ---- you wrote: > > Greetings, > > > > We are sorry, but the cut-off for Internet-Draft submissions was Friday, > > March 10 at 5pm ET. Your submission will not be retained (i.e. you > > need to resubmit) after March 7th. > > > > Any submissions received prior to March 26, 2000 will not be retained; > > they must be resubmitted. Internet-Draft submissions received on or after > > March 27 will be processed. However, Internet-Draft announcements will > > not be sent until after the meeting concludes. > > > > If you receive this announcement, your submission will NOT be processed. > > > > Thank you for your understanding. > > > > > > IETF Secretariat > > http://www.netaid.org ------------------------------------------------------------------------- Chip Sharp CTO Consulting Engineering Cisco Systems Reality - Love it or Leave it. ------------------------------------------------------------------------

Hi = all,
I've known that a large MG can = be=20 partitioned into multiple virtual logical MGs according to H.248 = protocol &=20 The requiements 10, each of which is controlled by separated = MGCs. 

If a large physical access gateway is partitioned into = two=20 virtual gateways G1 and G1 controlled by separated MGCs, would you mind=20 an example about = how to=20 establish a call between two subscribers S1 and S2 attached to G1 and=20 G2.

Regards

Wu=20 Yongji