From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec  1 05:12:51 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA11349
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 1 Dec 2000 05:12:50 -0500 (EST)
Received: from standards (47.234.32.16:2879) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBDD4B@standards.nortelnetworks.com>; Fri, 1 Dec 2000 4:54:04 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 151546 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 1 Dec 2000 04:54:04 -0500
Received: from hindon.hss.co.in (202.54.26.202:41001) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBDD4A@standards.nortelnetworks.com>; Fri, 1 Dec 2000 4:53:52
          -0500
Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in
          (8.10.0/8.10.0) with SMTP id eB1ACUV00558 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 1 Dec 2000 15:42:31 +0530
          (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          652569A8.0036D485 ; Fri, 1 Dec 2000 15:28:53 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <652569A8.0036D30E.00@sandesh.hss.hns.com>
Date:         Fri, 1 Dec 2000 15:34:19 +0530
Reply-To: knayar@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Kapil Nayar <knayar@HSS.HNS.COM>
Subject:      Difference between InService and Test Termination States
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi Tom,

What is the difference between "INSERVICE" and "TEST" from the MG perspective ?
Eg:
Do we have a media only in "INSERVICE" or
Do we allow an "ADD" only in "INSERVICE" etc.

-Kapil Nayar
Hughes Software Systems


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec  1 20:36:13 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27973
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 1 Dec 2000 20:36:13 -0500 (EST)
Received: from standards (47.234.32.16:2455) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE353@standards.nortelnetworks.com>; Fri, 1 Dec 2000 20:15:49 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 153571 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 1 Dec 2000 20:15:49 -0500
Received: from boreas.isi.edu by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBBE350@standards.nortelnetworks.com>; Fri, 1 Dec 2000 20:05:49
          -0500
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu
          (8.9.3/8.9.3) with ESMTP id RAA04676; Fri, 1 Dec 2000 17:23:12 -0800
          (PST)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Message-ID:  <200012020123.RAA04676@boreas.isi.edu>
Date:         Fri, 1 Dec 2000 17:23:12 -0800
Reply-To: RFC Editor <rfc-ed@ISI.EDU>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: RFC Editor <rfc-ed@ISI.EDU>
Subject:      RFC 3015 on Megaco Protocol Version 1.0
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 3015

        Title:      Megaco Protocol 1.0
        Author(s):  F. Cuervo, N. Greene, A. Rayhan, C. Huitema,
                    B. Rosen, J. Segers
        Status:     Standards Track
        Date:       November 2000
        Mailbox:    cuervo@nortelnetworks.com,
                    ngreene@nortelnetworks.com,
                    arayhan@nortelnetworks.com, huitema@microsoft.com,
                    brian.rosen@marconi.com, jsegers@lucent.com
        Pages:      178
        Characters: 385432
        Obsoletes:  2885, 2886

        I-D Tag:    draft-ietf-megaco-merged-01.txt

        URL:        ftp://ftp.isi.edu/in-notes/rfc3015.txt


This document defines the protocol used between elements of
a physically decomposed multimedia gateway, i.e. a Media Gateway
and a Media Gateway Controller.  The document is common text with
ITU-T Recommendation H.248 and is a result of applying the changes
yin RFC 2886 to the text of RFC 2885.

The protocol presented in this document meets the requirements
for a media gateway control protocol as presented in RFC 2805.

This document is a product of the Media Gateway Control Working Group
of the IETF.

This is now a Proposed Standard Protocol.

This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the
"Internet Official Protocol Standards" (STD 1) for the
standardization state and status of this protocol.  Distribution
of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body
help: ways_to_get_rfcs.  For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo
Submissions for Requests for Comments should be sent to
RFC-EDITOR@RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader
implementation to automatically retrieve the ASCII version
of the RFCs.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="RFC-INFO@RFC-EDITOR.ORG"

Content-Type: text/plain
Content-ID: <001201172131.RFC@RFC-EDITOR.ORG>

RETRIEVE: rfc
DOC-ID: rfc3015

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3015.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

Content-Type: text/plain
Content-ID: <001201172131.RFC@RFC-EDITOR.ORG>

--OtherAccess--
--NextPart--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Dec  3 07:32:56 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02634
	for <megaco-archive@LISTS.IETF.ORG>; Sun, 3 Dec 2000 07:32:55 -0500 (EST)
Received: from standards (47.234.32.16:4589) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBE997@standards.nortelnetworks.com>; 3 Dec 2000 7:13:47 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 155822 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 3 Dec 2000 07:13:47 -0500
Received: from mink.ecitele.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBBE996@standards.nortelnetworks.com>; 3 Dec 2000 7:13:46 -0500
Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by
          mink.ecitele.com (8.9.1a/8.9.1) with ESMTP id OAA25617 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sun, 3 Dec 2000 14:29:52 +0200
          (IST)
X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999
X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.3
             (Intl)|21 March 2000) at 03/12/2000 02:32:24 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Message-ID:  <OF1DB79DC6.61EEFA12-ONC22569AA.00439182@ecitele.com>
Date:         Sun, 3 Dec 2000 14:25:53 +0200
Reply-To: Shlomo.Kabaz@ECITELE.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Shlomo Kabaz  ECItelecom <Shlomo.Kabaz@ECITELE.COM>
Subject:      Audit of Packages
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hello list !

My MG just started working .

I want to ask It :
1. What are the packages supported by  all terminations in the MG ?
2. What are the packages supported by  ephemeral  terminations ?
3. What are the packages supported by  physical  terminations  ?

What are the commands that i have to write ?

Regards , shlomo .


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec  4 03:13:58 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA07186
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Dec 2000 03:13:58 -0500 (EST)
Received: from standards (47.234.32.16:2287) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBED27@standards.nortelnetworks.com>; Mon, 4 Dec 2000 2:54:28 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 157064 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Dec 2000 02:54:28 -0500
Received: from web5102.mail.yahoo.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBBED24@standards.nortelnetworks.com>; Mon, 4 Dec 2000 2:44:28
          -0500
Received: from [208.220.245.72] by web5102.mail.yahoo.com; Mon, 04 Dec 2000
          00:02:00 PST
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <20001204080200.6000.qmail@web5102.mail.yahoo.com>
Date:         Mon, 4 Dec 2000 00:02:00 -0800
Reply-To: Richie Wu <wuyongji@YAHOO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Richie Wu <wuyongji@YAHOO.COM>
Subject:      Modification of event and sig parameter ASN.1 syntax
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hello everybody,

I have some doubts about the definition of Event
Descriptor Parameters and Signal Descriptors in ASN.1.


In ASN.1 we have defined the syntax for event
parameters and additional signal parameters which were
described in package definition as the following
format:

Value ::= OCTET STRING

EventParameter ::= SEQUENCE
   {
        eventParameterName              Name,
        value                           Value
   }

SigParameter ::= SEQUENCE
   {
        sigParameterName                Name,
        value                           Value
   }

The issue is that we lose some information in Value
filed, because it loses the parameter type
information. And the appropriate items in ABNF which
matches the value field of the definition is defined
like:

parmValue            = (EQUAL alternativeValue/
INEQUAL VALUE)
   alternativeValue     = ( VALUE
                          / LSBRKT VALUE *(COMMA
VALUE) RSBRKT
                            ; sublist (i.e. A AND B
AND ...)
                          / LBRKT VALUE *(COMMA VALUE)
RBRKT
                            ; alternatives (i.e. A OR
B OR ...)
                          / LSBRKT VALUE COLON VALUE
RSBRKT )
                            ; range
   INEQUAL              = LWSP (">" / "<" / "#" ) LWSP

   LSBRKT               = LWSP "[" LWSP
   RSBRKT               = LWSP "]" LWSP

On  the other hand, as per the section “12.1.2
Properties”, we have defined the ASN.1 syntax of
property parameters in package which is showed below:

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

which have the samilar description in section 12.

So, can we modify the appropriate ASN.1 definition
like this:

SigsEventsParm ::= SEQUENCE
   {
        name            Name,
        value           SEQUENCE OF OCTET STRING,
        extraInfo       CHOICE
                {
                        relation        Relation,
                        range           BOOLEAN,
                        sublist         BOOLEAN
                } OPTIONAL,
        ...
}

EventParameter ::= SigsEventsParm
SigParameter     ::= SigsEventsParm

Or we modify the Value definition while leave the
other as it is:
Value ::= SEQUENCE
   {
        value           SEQUENCE OF OCTET STRING,
        extraInfo       CHOICE
                {
                        relation        Relation,
                        range           BOOLEAN,
                        sublist         BOOLEAN
                } OPTIONAL,
        ...
}

Best regards,

Richie Wu



=====
Huawei Technologies India Private Limited

Unit 10, 2nd Floor, Innovator Block
International Tech Park, Whitefield Main Road
Bangalore 560 066, India
TEL: 0091-80-841 0061/0753/0755
FAX: 0091-80-841 0063

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec  4 08:14:18 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12529
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Dec 2000 08:14:17 -0500 (EST)
Received: from standards (47.234.32.16:3754) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBEEC1@standards.nortelnetworks.com>; Mon, 4 Dec 2000 7:55:05 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 157570 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Dec 2000 07:55:05 -0500
Received: from mail.axestech.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBBEEA8@standards.nortelnetworks.com>; Mon, 4 Dec 2000 7:45:04
          -0500
Received: by MAIL with Internet Mail Service (5.5.1960.3) id <V76R3X6X>; Mon, 4
          Dec 2000 07:05:46 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Message-ID:  <801E09D925AED411ABF400010254F18701D70C@MAIL>
Date:         Mon, 4 Dec 2000 07:05:46 -0600
Reply-To: J Ramachandra <JRamachandra@AXESTECH.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: J Ramachandra <JRamachandra@AXESTECH.COM>
Subject:      Provisional Response Timer Value
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi list,

I was trying to understand the usage of 'Provisional Response Timer'.
After reading through the sections D.1.4 and E.2.1, I have the following
doubts. Could some one clarify?

1. The section D.1.4 specifies "The root termination has a property
(ProvisionalResponseTimerValue), which can be set to the requested
maximum number of milliseconds between receipt of a command and
transmission of the TransactionPending response". Does it mean this
timer value is used for sending the TransactionPending by the entity
RECEIVING the TransactionRequest? If so, it is only the worst case or
maximum self (MGC/MG)execution time and no network delay factor coming
into picture.

2. The section E.2.1 for propertyID:ProvisionalResponseTimerValue
"Indicates the time within which to expect a Pending Response if a
Transaction cannot be completed.  Initially set to normalMGExecutionTime
or normalMGCExecutionTime as appropriate, plus network delay, but may be
lowered". Does it mean it is a timer started at the entity SENDING the
TransactionRequest and is based on the remote (MG/MGC) Execution time
plus network delay?

3. Which one of the above is correct; (1) or (2)? It can not be both, as
both are not same and base root package can only hold one value.

4. The wordings from (2) indicates one has to start two timers while
sending TransactionRequest. One for expecting transactionPending and
another for normal repetition timer. Is it correct? If not what is the
timer started while sending a transactionRequest?

5. Why do we need this property in Base root Package separately? Is it
not derivable from normalMGExecutionTime/normalMGCExecutionTime and the
network delay?

6. The secion D.1.4 also specifies "Entities that receive a Transaction
Pending shall switch to a different repetition timer for repeating
requests". What is different repetition timer? Is it ProvisionalResponse
TimerValue? Is the same timer value used for subsequent
transactionPending received till you receive TransactionReply - i.e. no
exponetially increasing timer as done with normal repetiton timer?

7. Finally, what is the criteria for sending TransactionPending? The
same section D.1.4 specifies "They SHOULD send this response if they
receive a repetition of a transaction that is still being executed". Is
this the criteria or after timeout as in (1) above. Do one necessarily
has to wait till a  transactionRequest is repeated from the remote end?

Sorry, if the mail is bit long. My intention is to make my doubt clear
and expecting the answers to specific items listed.

Thanks for your patience,

- J.K. Ramachandra,
  ipGen inc.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec  4 08:17:56 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13437
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Dec 2000 08:17:55 -0500 (EST)
Received: from standards (47.234.32.16:3754) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBEED8@standards.nortelnetworks.com>; Mon, 4 Dec 2000 7:57:56 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 157579 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Dec 2000 07:57:56 -0500
Received: from hotmail.com (f39.law4.hotmail.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBEEB0@standards.nortelnetworks.com>; Mon, 4 Dec 2000 7:47:56
          -0500
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon,
          4 Dec 2000 05:05:28 -0800
Received: from 192.187.17.98 by lw4fd.law4.hotmail.msn.com with HTTP; Mon, 04
          Dec 2000 13:05:28 GMT
X-Originating-IP: [192.187.17.98]
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 04 Dec 2000 13:05:28.0551 (UTC)
                       FILETIME=[DFDAEF70:01C05DF2]
Message-ID:  <F39ZeL6uXHaUhygiFUq00003a39@hotmail.com>
Date:         Mon, 4 Dec 2000 13:05:28 -0000
Reply-To: Willfoor Orey DelaBarraca <willfoor@HOTMAIL.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Willfoor Orey DelaBarraca <willfoor@HOTMAIL.COM>
Subject:      some questions, opinions wanted
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I need help to answer any this questions;any help would be very thanked!

-Is the megaco (h.248) enough nature like to be widely deployed?In which
"enviroments"?Which significant references do you know?

-do you think it will the "leader" solution in the market?

thank you for your help
_____________________________________________________________________________________
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec  4 09:19:11 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00278
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Dec 2000 09:19:11 -0500 (EST)
Received: from standards (47.234.32.16:3754) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBEF87@standards.nortelnetworks.com>; Mon, 4 Dec 2000 9:00:12 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 157861 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Dec 2000 09:00:11 -0500
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBBEF86@standards.nortelnetworks.com>; Mon, 4 Dec 2000 9:00:11
          -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id JAA22849; Mon, 4 Dec 2000 09:17:42 -0500 (EST)
Received: from stl-server-01.pit.comms.marconi.com
          (stl-server-01.pit.comms.marconi.com [169.144.36.27]) by
          mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA05284;
          Mon, 4 Dec 2000 09:17:41 -0500 (EST)
Received: by stl-server-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <YB6WQRVM>; Mon, 4 Dec 2000 09:17: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:  <4FBEA8857476D311A03300204840E1CF01A6EAF5@whq-msgusr-02.pit.comms.marconi.com>
Date:         Mon, 4 Dec 2000 09:17:40 -0500
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: Audit of Packages
X-To:         "Shlomo.Kabaz@ECITELE.COM" <Shlomo.Kabaz@ECITELE.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Context=*{W-AuditValue=*{Audit{Packages}}}
gets you all the packages in the gateway.

To determine which are implemented by ephemerals, you would have
to know the naming pattern of the MG to understand how to construct
an appropriate wildcarded Audit command.  Same with physicals.
It's kind of hard to justify why you need to know what packages
are implemented by all ephemerals, or all physicals.  You need
to know all the packages to know if you can serve the MG.
You need to know packages associated with a set of terminations
that can be treated identically, and to do that, you need to
know how many such sets there are, and how they are named.

My name pattern proposal does the latter.

Brian

> -----Original Message-----
> From: Shlomo Kabaz ECItelecom [mailto:Shlomo.Kabaz@ECITELE.COM]
> Sent: Sunday, December 03, 2000 7:26 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Audit of Packages
>
>
> Hello list !
>
> My MG just started working .
>
> I want to ask It :
> 1. What are the packages supported by  all terminations in the MG ?
> 2. What are the packages supported by  ephemeral  terminations ?
> 3. What are the packages supported by  physical  terminations  ?
>
> What are the commands that i have to write ?
>
> Regards , shlomo .
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec  4 09:37:22 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06801
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Dec 2000 09:37:21 -0500 (EST)
Received: from standards (47.234.32.16:3754) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBEFAE@standards.nortelnetworks.com>; Mon, 4 Dec 2000 9:18:13 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 157910 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Dec 2000 09:18:13 -0500
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBBEFAD@standards.nortelnetworks.com>; Mon, 4 Dec 2000 9:18:13
          -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id JAA25065; Mon, 4 Dec 2000 09:35:43 -0500 (EST)
Received: from stl-server-01.pit.comms.marconi.com
          (stl-server-01.pit.comms.marconi.com [169.144.36.27]) by
          mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA11714;
          Mon, 4 Dec 2000 09:35:42 -0500 (EST)
Received: by stl-server-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <YB6WQS0P>; Mon, 4 Dec 2000 09:35:33 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF01A6EAF6@whq-msgusr-02.pit.comms.marconi.com>
Date:         Mon, 4 Dec 2000 09:35:25 -0500
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: Provisional Response Timer Value
X-To:         J Ramachandra <JRamachandra@AXESTECH.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I vaguely recall a discussion of whether the parameters include network
delay,
and I recall that they do.

> 1. The section D.1.4 specifies "The root termination has a property
> (ProvisionalResponseTimerValue), which can be set to the requested
> maximum number of milliseconds between receipt of a command and
> transmission of the TransactionPending response". Does it mean this
> timer value is used for sending the TransactionPending by the entity
> RECEIVING the TransactionRequest? If so, it is only the worst case or
> maximum self (MGC/MG)execution time and no network delay factor coming
> into picture.
It is the internal processing time, plus an estimate of network time.
It is NOT the worst case time to execute a command, it is the maximum time
the entity will wait for a command to complete before sending a
Pending response (plus the estimated network delay).

>
> 2. The section E.2.1 for propertyID:ProvisionalResponseTimerValue
> "Indicates the time within which to expect a Pending Response if a
> Transaction cannot be completed.  Initially set to
> normalMGExecutionTime
> or normalMGCExecutionTime as appropriate, plus network delay,
> but may be
> lowered". Does it mean it is a timer started at the entity SENDING the
> TransactionRequest and is based on the remote (MG/MGC) Execution time
> plus network delay?
No the timer is started by the entity RECIEVING the Request.  Of course,
the timer is actually set to the max time before sending a pend WITHOUT the
estimated network delay.

>
> 3. Which one of the above is correct; (1) or (2)? It can not
> be both, as
> both are not same and base root package can only hold one value.
Covered above.  It's the receiver, and the value includes network delay

>
> 4. The wordings from (2) indicates one has to start two timers while
> sending TransactionRequest. One for expecting transactionPending and
> another for normal repetition timer. Is it correct? If not what is the
> timer started while sending a transactionRequest?
The SENDER runs a timer which is used to trigger request repetitions.
The RECIEVER runs a timer which is used to trigger Pending responses.
>
> 5. Why do we need this property in Base root Package separately? Is it
> not derivable from
> normalMGExecutionTime/normalMGCExecutionTime and the
> network delay?
See above - one is a timer for the sender, the other if for the receiver.

>
> 6. The secion D.1.4 also specifies "Entities that receive a
> Transaction
> Pending shall switch to a different repetition timer for repeating
> requests". What is different repetition timer? Is it
> ProvisionalResponse
> TimerValue? Is the same timer value used for subsequent
> transactionPending received till you receive TransactionReply
> - i.e. no
> exponetially increasing timer as done with normal repetition timer?
This means that when you get a pending response, you should know that
the next response should be determined by the ProvisionalResponseTimerValue
and not the normalMGExecutionTime.  So the timer for the SENDER should
be reset to ProvisionalResponseTimerValue.

>
> 7. Finally, what is the criteria for sending TransactionPending? The
> same section D.1.4 specifies "They SHOULD send this response if they
> receive a repetition of a transaction that is still being
> executed". Is
> this the criteria or after timeout as in (1) above. Do one necessarily
> has to wait till a  transactionRequest is repeated from the
> remote end?
Pending is sent when you aren't finished executing, but your pending timer
expires.  The SENDER sends a Pend to the Receiver, which resets it's
repetition
timer.

In the normal case, you will receive the Pend before your repetition timer
times out, but what if it doesn't.  You send a repeat of the request.  When
you do get the Pend, you reset your repetition timer (holding off sending
of yet another repetition until at least ProvisionalResponseTimerValue from
the receipt of the pend.  The RECIEVER of the request sees the duplicate
request
after he sends a Pend.  We recommend that it send another Pend at that time.
The RECIEVER then sees two pends, the (delayed) original pend, plus the one
that is sent in response to the duplicate request.  It resets it's timer
again,
and continues waiting for (a) another pend or (b) a Response.

Brian


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec  4 09:44:29 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09107
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Dec 2000 09:44:29 -0500 (EST)
Received: from standards (47.234.32.16:3754) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBEFD6@standards.nortelnetworks.com>; Mon, 4 Dec 2000 9:25:31 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 157957 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Dec 2000 09:25:31 -0500
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBBEFD5@standards.nortelnetworks.com>; Mon, 4 Dec 2000 9:25:31
          -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id JAA26191; Mon, 4 Dec 2000 09:43:01 -0500 (EST)
Received: from stl-server-01.pit.comms.marconi.com
          (stl-server-01.pit.comms.marconi.com [169.144.36.27]) by
          mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA14992;
          Mon, 4 Dec 2000 09:43:00 -0500 (EST)
Received: by stl-server-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <YB6WQTX3>; Mon, 4 Dec 2000 09:42:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF01A6EAF7@whq-msgusr-02.pit.comms.marconi.com>
Date:         Mon, 4 Dec 2000 09:42:48 -0500
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: some questions, opinions wanted
X-To:         Willfoor Orey DelaBarraca <willfoor@HOTMAIL.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is, of course, an unanswerable question.

My opinion is that the protocol is stable enough to be deployed,
but it is still early, so you should expect some interoperability issues,
and thus you should expect to participate in the interop events that
are occurring if you are creating a Megaco implementation, or, if you are
a customer, you should require evidence that your vendor successfully
participates in these events.

The markets it will be deployed in are pretty varied.  It seems to me
that it will find the most use in larger gateways where the compute
load of the signalling warrants removing it to a real computer rather than
embedding it in the gateway.  It will also be used in CPE where the network
operator is not prepared to allow it's actual signalling protocols to
execute on customer premise equipment, and thus needs a lower level protocol
to remote the signalling to an entity it controls.

The major issue for Megaco/H.248 is whether it will supplant MGCP.
I think it will, but that is a guess.  We have some evidence that
some carriers are now telling vendors they will require Megaco in the
future,
where we have very few carriers telling vendors they will require MGCP.
The obvious exception is the PacketCable specs, which are built around MGCP.

Brian

> -----Original Message-----
> From: Willfoor Orey DelaBarraca [mailto:willfoor@HOTMAIL.COM]
> Sent: Monday, December 04, 2000 8:05 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: some questions, opinions wanted
>
>
> I need help to answer any this questions;any help would be
> very thanked!
>
> -Is the megaco (h.248) enough nature like to be widely
> deployed?In which
> "enviroments"?Which significant references do you know?
>
> -do you think it will the "leader" solution in the market?
>
> thank you for your help
> ______________________________________________________________
> _______________________
> Get more from the Web.  FREE MSN Explorer download :
> http://explorer.msn.com
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec  4 11:09:37 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04219
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Dec 2000 11:09:37 -0500 (EST)
Received: from standards (47.234.32.16:4144) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF009@standards.nortelnetworks.com>; Mon, 4 Dec 2000 10:50:29 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 158020 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Dec 2000 10:50:29 -0500
Received: from hotmail.com (f147.law4.hotmail.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBF008@standards.nortelnetworks.com>; Mon, 4 Dec 2000
          10:50:28 -0500
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon,
          4 Dec 2000 08:08:01 -0800
Received: from 192.187.17.98 by lw4fd.law4.hotmail.msn.com with HTTP; Mon, 04
          Dec 2000 16:08:01 GMT
X-Originating-IP: [192.187.17.98]
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 04 Dec 2000 16:08:01.0341 (UTC)
                       FILETIME=[603A0ED0:01C05E0C]
Message-ID:  <F147FT3kMUVfNIJWNDI00003ec8@hotmail.com>
Date:         Mon, 4 Dec 2000 16:08:01 -0000
Reply-To: Willfoor Orey DelaBarraca <willfoor@HOTMAIL.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Willfoor Orey DelaBarraca <willfoor@HOTMAIL.COM>
Subject:      Future evolution of MEGACO
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

whats is your opinion about future evotion of megaco, according to actual
trends??

thank you for your help..adios!
_____________________________________________________________________________________
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec  4 11:21:32 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07751
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Dec 2000 11:21:30 -0500 (EST)
Received: from standards (47.234.32.16:4144) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF028@standards.nortelnetworks.com>; Mon, 4 Dec 2000 11:02:25 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 158058 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Dec 2000 11:02:25 -0500
Received: from hotmail.com (f253.law4.hotmail.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBF027@standards.nortelnetworks.com>; Mon, 4 Dec 2000
          11:02:24 -0500
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon,
          4 Dec 2000 08:19:57 -0800
Received: from 192.187.17.98 by lw4fd.law4.hotmail.msn.com with HTTP; Mon, 04
          Dec 2000 16:19:57 GMT
X-Originating-IP: [192.187.17.98]
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 04 Dec 2000 16:19:57.0651 (UTC)
                       FILETIME=[0B2E4A30:01C05E0E]
Message-ID:  <F253p7vXee4fDGCl9Fo00003b55@hotmail.com>
Date:         Mon, 4 Dec 2000 16:19:57 -0000
Reply-To: Willfoor Orey DelaBarraca <willfoor@HOTMAIL.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Willfoor Orey DelaBarraca <willfoor@HOTMAIL.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

which are the most important MEGACO solution sellers?which will the most
indicated ones for a little benchmark?or do you thinck this is more suitable
for the convergence od data and telephony in a corporation?

thank you for your help
_____________________________________________________________________________________
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec  4 11:28:43 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09871
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Dec 2000 11:28:43 -0500 (EST)
Received: from standards (47.234.32.16:4144) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF04B@standards.nortelnetworks.com>; Mon, 4 Dec 2000 11:09:35 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 158102 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Dec 2000 11:09:35 -0500
Received: from hotmail.com (f164.law4.hotmail.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBF04A@standards.nortelnetworks.com>; Mon, 4 Dec 2000
          11:09:34 -0500
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon,
          4 Dec 2000 08:27:07 -0800
Received: from 192.187.17.98 by lw4fd.law4.hotmail.msn.com with HTTP; Mon, 04
          Dec 2000 16:27:07 GMT
X-Originating-IP: [192.187.17.98]
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 04 Dec 2000 16:27:07.0696 (UTC)
                       FILETIME=[0B81F300:01C05E0F]
Message-ID:  <F1641dsPX4GaHdE7RED00003fdd@hotmail.com>
Date:         Mon, 4 Dec 2000 16:27:07 -0000
Reply-To: Willfoor Orey DelaBarraca <willfoor@HOTMAIL.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Willfoor Orey DelaBarraca <willfoor@HOTMAIL.COM>
Subject:      about megaco solutions
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

first of all, sorry about my poor english and my small knowledge of megaco,
i have just started in it...

this are my questions


which are the most important MEGACO solution sellers?which would bethe most
indicated ones for a little benchmark?or do you thinck this is more suitable
for the convergence od data and telephony in a corporation?

thank you for your help

_____________________________________________________________________________________
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec  4 11:38:44 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14307
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Dec 2000 11:38:44 -0500 (EST)
Received: from standards (47.234.32.16:4144) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF071@standards.nortelnetworks.com>; Mon, 4 Dec 2000 11:19:33 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 158149 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Dec 2000 11:19:33 -0500
Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBF070@standards.nortelnetworks.com>; Mon, 4 Dec 2000
          11:19:32 -0500
Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by
          ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA29411
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 4 Dec 2000 11:37:05
          -0500 (EST)
Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by
          ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA29396
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 4 Dec 2000 11:37:05
          -0500 (EST)
Received: from lucent.com (pctla [135.3.130.39]) by teton.mh.lucent.com
          (8.8.8+Sun/8.8.8) with ESMTP id LAA07296 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 4 Dec 2000 11:35:29 -0500
          (EST)
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------C9531FE93A04CEA8B9C147AD"
Message-ID:  <3A2BC877.6A5A2224@lucent.com>
Date:         Mon, 4 Dec 2000 11:38:15 -0500
Reply-To: Terry L Anderson <tla@LUCENT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Terry L Anderson <tla@LUCENT.COM>
Organization: Lucent Technologies
Subject:      TerminationID
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.
--------------C9531FE93A04CEA8B9C147AD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

It would be useful for TerminationID to permit a comma separated list.
Since it supports wildcards it often evaluates to a list anyway, but
currently an explicit list is not permitted.  Extending it this way
would have several advantages:
1. it would allow addressing a group of terminations that cannot be
addressed with a wildcard (e.g,
AuditValue = P1/1,P2/2 or AuditValue = P1/*,P3/* )
2. it would permit addressing both active terminations and those in ROOT
in one command (eg. AuditValue=*,ROOT {...} )
Since there is no wildcard that includes ROOT.

The same could be true of Context.  Allowing Context = *,NULL
could be useful.

Obviously this could not be included in V1, but perhaps we should
consider this for V2.
--
------------------------------------------------------------
Terry L Anderson              mailto:tla@lucent.com
Tel:908.582.7013   Fax:908.582.6729
Pager:800.759.8352 pin 1704572   1704572@skytel.com
Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla


--------------C9531FE93A04CEA8B9C147AD
Content-Type: text/x-vcard; charset=us-ascii;
 name="tla.vcf"
Content-Description: Card for Terry L Anderson
Content-Disposition: attachment;
 filename="tla.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard
n:Anderson;Terry L
tel;pager:800.759.8352 pin 1704572
tel;fax:908.582.6729
tel;work:908.582.7013
x-mozilla-html:TRUE
url:http://its.lucent.com/~tla
org:Lucent / InterNetworking Systems;VoIP Access Networks / Applications Group
version:2.1
email;internet:tla@lucent.com
title:DMTS
adr;quoted-printable:;;600 Mountain Av=0D=0ARm 2B-121;Murray Hill;NJ;07974;USA
note;quoted-printable:http://www.gti.net/tla  or http://teton.mh.lucent.com/~tla (Lucent internal)=0D=0A18E343126 / 10034134
x-mozilla-cpt:;-23792
fn:Terry L Anderson
end:vcard

--------------C9531FE93A04CEA8B9C147AD--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec  4 11:58:56 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22696
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Dec 2000 11:58:56 -0500 (EST)
Received: from standards (47.234.32.16:3367) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF092@standards.nortelnetworks.com>; Mon, 4 Dec 2000 11:39:51 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 158188 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Dec 2000 11:39:51 -0500
Received: from fox.bos.ascend.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBBF090@standards.nortelnetworks.com>; Mon, 4 Dec 2000 11:29:50
          -0500
Received: by fox.bos.ascend.com with Internet Mail Service (5.5.2650.21) id
          <R4CSZ5AZ>; Mon, 4 Dec 2000 11:47:10 -0500
Importance: high
X-Priority: 1
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <D3453BACFF44D311ADCE0090278A7D41027D872C@fox.bos.ascend.com>
Date:         Mon, 4 Dec 2000 11:47:09 -0500
Reply-To: "Araveti, Thirumala" <araveti@LUCENT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Araveti, Thirumala" <araveti@LUCENT.COM>
Subject:      Need H.248/MEGACO info to start with..
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi all,
    I am new to MEGACO/H.248 protocol, though have some knowledge in VoIP
protocols such as IPDC, H.323, SIP.
Can any one suggest me some documents/tutorials that introduces/explains
H.248 to start with.
Thanks in advance.
Regards

Thirumala Gupta, Araveti
OpeNet Solutions
Lucent Technologies, Inc.              Work Phone :(508)-486-2379
55 Fairbanks Blvd,                          Home Phone :(508)-229-8411
Marlboro, MA-01752, USA.          E-mail           : araveti@lucent.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec  4 12:50:17 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11326
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Dec 2000 12:50:17 -0500 (EST)
Received: from standards (47.234.32.16:1485) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF126@standards.nortelnetworks.com>; Mon, 4 Dec 2000 12:31:11 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 158385 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Dec 2000 12:31:11 -0500
Received: from hotmail.com (f216.law4.hotmail.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBF125@standards.nortelnetworks.com>; Mon, 4 Dec 2000
          12:31:11 -0500
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon,
          4 Dec 2000 09:48:44 -0800
Received: from 192.187.17.98 by lw4fd.law4.hotmail.msn.com with HTTP; Mon, 04
          Dec 2000 17:48:43 GMT
X-Originating-IP: [192.187.17.98]
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
X-OriginalArrivalTime: 04 Dec 2000 17:48:44.0217 (UTC)
                       FILETIME=[720FC290:01C05E1A]
Message-ID:  <F216ImjVTML0SLFqE4I00003deb@hotmail.com>
Date:         Mon, 4 Dec 2000 17:48:43 -0000
Reply-To: Willfoor Orey DelaBarraca <willfoor@HOTMAIL.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Willfoor Orey DelaBarraca <willfoor@HOTMAIL.COM>
Subject:      megaco interoperability
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

hi there everybody

where can i get the first megaco interoperability report?is it available?

thank you for your help
_____________________________________________________________________________________
Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec  4 13:07:32 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15378
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Dec 2000 13:07:31 -0500 (EST)
Received: from standards (47.234.32.16:1485) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF14F@standards.nortelnetworks.com>; Mon, 4 Dec 2000 12:48:22 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 158435 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Dec 2000 12:48:21 -0500
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBBF14E@standards.nortelnetworks.com>; Mon, 4 Dec 2000 12:48:21
          -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id NAA21875; Mon, 4 Dec 2000 13:05:46 -0500 (EST)
Received: from stl-server-01.pit.comms.marconi.com
          (stl-server-01.pit.comms.marconi.com [169.144.36.27]) by
          mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA03952;
          Mon, 4 Dec 2000 13:05:46 -0500 (EST)
Received: by stl-server-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <YB6WRG4B>; Mon, 4 Dec 2000 13:05:47 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF01A6EB0E@whq-msgusr-02.pit.comms.marconi.com>
Date:         Mon, 4 Dec 2000 13:05:38 -0500
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: megaco interoperability
X-To:         Willfoor Orey DelaBarraca <willfoor@HOTMAIL.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

draft-rosen-megaco-interop-1-report-00.txt

> -----Original Message-----
> From: Willfoor Orey DelaBarraca [mailto:willfoor@HOTMAIL.COM]
> Sent: Monday, December 04, 2000 12:49 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: megaco interoperability
>
>
> hi there everybody
>
> where can i get the first megaco interoperability report?is
> it available?
>
> thank you for your help
> ______________________________________________________________
> _______________________
> Get more from the Web.  FREE MSN Explorer download :
> http://explorer.msn.com
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec  4 13:40:01 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23437
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Dec 2000 13:40:00 -0500 (EST)
Received: from standards (47.234.32.16:1485) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF186@standards.nortelnetworks.com>; Mon, 4 Dec 2000 13:20:34 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 158508 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Dec 2000 13:20:33 -0500
Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBF185@standards.nortelnetworks.com>; Mon, 4 Dec 2000
          13:20:32 -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 NAA11714
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 4 Dec 2000 13:38:04
          -0500 (EST)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by
          auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id NAA11704
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 4 Dec 2000 13:38:04
          -0500 (EST)
Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id NAA15095; Mon, 4 Dec
          2000 13:38:02 -0500
Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id
          NAA15088; Mon, 4 Dec 2000 13:38:01 -0500
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Original-CC: MEGACO@STANDARDS.NORTELNETWORKS.COM
References: <20001204080200.6000.qmail@web5102.mail.yahoo.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3A2BE43B.9BC0E1CD@lucent.com>
Date:         Mon, 4 Dec 2000 13:36:43 -0500
Reply-To: Troy Cauble <troy@bell-labs.com>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Troy Cauble <troy@LUCENT.COM>
Subject:      Re: Modification of event and sig parameter ASN.1 syntax
X-To:         Richie Wu <wuyongji@YAHOO.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Yes, please!  I've brought up the OCTET STRING problem
before, and "double wrapping" the values was discussed.

But we didn't talk about the missing Relation information
(>, <, !=, etc.) !

If people like your first proposal, I'd suggest that
PropertyParm be reused rather than creating new constructs
just like it.  The second version is good too; that construct
maps directly to the ABNF parmValue.

Either of these proposals would help a great deal.  Since
we're discussing changing the ASN.1, I'd propose we go a
step further and get rid of the OCTET STRING hole, as
follows.


        Value ::= CHOICE        -- or another name, depending
        {                       -- on which model below is chosen

                boolValue       BOOLEAN,
                intValue        INTEGER,
                stringValue     IA5String,
                -- etc.  for all the property/parameter
                -- Types in section 12.1.2 and 12.2
        }

-troy

Richie Wu wrote:
>
> Hello everybody,
>
> I have some doubts about the definition of Event
> Descriptor Parameters and Signal Descriptors in ASN.1.
>
> In ASN.1 we have defined the syntax for event
> parameters and additional signal parameters which were
> described in package definition as the following
> format:
>
> Value ::= OCTET STRING
>
> EventParameter ::= SEQUENCE
>    {
>         eventParameterName              Name,
>         value                           Value
>    }
>
> SigParameter ::= SEQUENCE
>    {
>         sigParameterName                Name,
>         value                           Value
>    }
>
> The issue is that we lose some information in Value
> filed, because it loses the parameter type
> information. And the appropriate items in ABNF which
> matches the value field of the definition is defined
> like:
>
> parmValue            = (EQUAL alternativeValue/
> INEQUAL VALUE)
>    alternativeValue     = ( VALUE
>                           / LSBRKT VALUE *(COMMA
> VALUE) RSBRKT
>                             ; sublist (i.e. A AND B
> AND ...)
>                           / LBRKT VALUE *(COMMA VALUE)
> RBRKT
>                             ; alternatives (i.e. A OR
> B OR ...)
>                           / LSBRKT VALUE COLON VALUE
> RSBRKT )
>                             ; range
>    INEQUAL              = LWSP (">" / "<" / "#" ) LWSP
>
>    LSBRKT               = LWSP "[" LWSP
>    RSBRKT               = LWSP "]" LWSP
>
> On  the other hand, as per the section ?12.1.2
> Properties?, we have defined the ASN.1 syntax of
> property parameters in package which is showed below:
>
> PropertyParm ::= SEQUENCE
>    {
>         name            PkgdName,
>         value           SEQUENCE OF OCTET STRING,
>         extraInfo       CHOICE
>                 {
>                         relation        Relation,
>                         range           BOOLEAN,
>                         sublist         BOOLEAN
>                 } OPTIONAL,
>         ...
> }
>
> which have the samilar description in section 12.
>
> So, can we modify the appropriate ASN.1 definition
> like this:
>
> SigsEventsParm ::= SEQUENCE
>    {
>         name            Name,
>         value           SEQUENCE OF OCTET STRING,
>         extraInfo       CHOICE
>                 {
>                         relation        Relation,
>                         range           BOOLEAN,
>                         sublist         BOOLEAN
>                 } OPTIONAL,
>         ...
> }
>
> EventParameter ::= SigsEventsParm
> SigParameter     ::= SigsEventsParm
>
> Or we modify the Value definition while leave the
> other as it is:
> Value ::= SEQUENCE
>    {
>         value           SEQUENCE OF OCTET STRING,
>         extraInfo       CHOICE
>                 {
>                         relation        Relation,
>                         range           BOOLEAN,
>                         sublist         BOOLEAN
>                 } OPTIONAL,
>         ...
> }
>
> Best regards,
>
> Richie Wu
>
> =====
> Huawei Technologies India Private Limited
>
> Unit 10, 2nd Floor, Innovator Block
> International Tech Park, Whitefield Main Road
> Bangalore 560 066, India
> TEL: 0091-80-841 0061/0753/0755
> FAX: 0091-80-841 0063
>
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Shopping - Thousands of Stores. Millions of Products.
> http://shopping.yahoo.com/


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec  4 14:04:28 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00384
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Dec 2000 14:04:27 -0500 (EST)
Received: from standards (47.234.32.16:1485) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF1C2@standards.nortelnetworks.com>; Mon, 4 Dec 2000 13:45:25 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 158585 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Dec 2000 13:45:25 -0500
Received: from standards (47.234.32.16:1485) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBBF1C1@standards.nortelnetworks.com>; Mon, 4 Dec 2000 13:45:25
          -0500
Message-ID:  <MEGACO%2000120413452570@STANDARDS.NORTELNETWORKS.COM>
Date:         Mon, 4 Dec 2000 13:45:25 -0500
Reply-To: Tom Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: megaco interoperability
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

On Mon, 4 Dec 2000 17:48:43 -0000, Willfoor Orey DelaBarraca <willfoor@HOTMAIL.COM> wrote:

>hi there everybody
>
>where can i get the first megaco interoperability report?is it available?
>
>thank you for your help
>_____________________________________________________________________________________
>Get more from the Web.  FREE MSN Explorer download : http://explorer.msn.com

See draft-rosen-megaco-interop-1-report-00.txt  (October 2000).

Tom Taylor


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec  4 14:19:12 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05043
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Dec 2000 14:19:12 -0500 (EST)
Received: from standards (47.234.32.16:1485) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF1EB@standards.nortelnetworks.com>; Mon, 4 Dec 2000 14:00:01 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 158633 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Dec 2000 14:00:00 -0500
Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBF1E8@standards.nortelnetworks.com>; Mon, 4 Dec 2000
          14:00:00 -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 OAA04171
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 4 Dec 2000 14:17:33
          -0500 (EST)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by
          auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id OAA04164
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 4 Dec 2000 14:17:32
          -0500 (EST)
Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA15692; Mon, 4 Dec
          2000 14:17:30 -0500
Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id
          OAA15689; Mon, 4 Dec 2000 14:17:29 -0500
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3A2BED7C.6FDD4BA0@lucent.com>
Date:         Mon, 4 Dec 2000 14:16:12 -0500
Reply-To: Troy Cauble <troy@bell-labs.com>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Troy Cauble <troy@LUCENT.COM>
Subject:      MEGACO: More Annex C Questions
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi all,


Annex C is not called a package, but is very much like
a package (package name 0x00).

I assume that an MG does not have to support every
Annex C property (unlike a package).  Is this correct?

Do they have to support every property in a subsection
that they support (C.1, C.2, etc.)?

Each of these property definitions should state if they're
read/write or read-only, shouldn't they?


-troy


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec  4 15:02:23 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15065
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Dec 2000 15:02:22 -0500 (EST)
Received: from standards (47.234.32.16:4161) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF212@standards.nortelnetworks.com>; Mon, 4 Dec 2000 14:43:15 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 158680 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Dec 2000 14:43:14 -0500
Received: from zmers013 (47.124.1.40:53593) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBBF211@standards.nortelnetworks.com>; Mon, 4 Dec 2000 14:33:09
          -0500
Received: from smtprch2.nortel.com (actually erchg0k) by zmers013; Mon, 4 Dec
          2000 14:50:10 -0500
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch2.nortel.com; Mon, 4 Dec 2000 13:45:36 -0600
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <YCBXW10X>; Mon, 4 Dec 2000 13:49:52 -0600
X-Mailer: Internet Mail Service (5.5.2652.35)
X-Orig: <taylor@americasm01.nt.com>
Message-ID:  <28560036253BD41191A10000F8BCBD1103061EC7@zcard00g.ca.nortel.com>
Date:         Mon, 4 Dec 2000 13:49:41 -0600
Reply-To: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Subject:      RFC 3015
X-To:         ITU-SG16@MAILBAG.INTEL.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

At least on the web interface (the only way I seem to be able to get to look
at Megaco correspondence these days), the announce of publication of RFC
3015 seemed to be garbled.  RFC 3015 reproduces the content of H.248 as
decided last June.  It obsoletes the combination of RFCs 2885 and 2886, but
does not change what was specified by the combination of those two
documents.

May we find a less process-ridden way to put out any updates to the
protocol!

Tom Taylor
+1 613 736 0961
taylor@nortelnetworks.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec  4 16:52:53 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13119
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Dec 2000 16:52:50 -0500 (EST)
Received: from standards (47.234.32.16:2518) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF273@standards.nortelnetworks.com>; Mon, 4 Dec 2000 16:32:55 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 158798 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Dec 2000 16:32:55 -0500
Received: from dnsmx2pya.telcordia.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBBF267@standards.nortelnetworks.com>; Mon, 4 Dec 2000 16:22:53
          -0500
Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com
          [128.96.246.8]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with SMTP id
          QAA10004; Mon, 4 Dec 2000 16:33:41 -0500 (EST)
Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4  (830.2
          3-23-1999))  id 852569AB.00766D58 ; Mon, 4 Dec 2000 16:33:32 -0500
X-Lotus-FromDomain: TELCORDIA
Mime-Version: 1.0
Content-type: multipart/mixed;
              Boundary="0__=1wj55wbMuTLaPmr8Vlgwmlg8x6MSQcPhFaLr2uYDP8KJkX3qiio0mrEY"
Content-Disposition: inline
Message-ID:  <852569AB.00766C99.00@notes949.cc.telcordia.com>
Date:         Mon, 4 Dec 2000 16:31:46 -0500
Reply-To: "Petros N. Mouchtaris" <pmouchta@TELCORDIA.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Petros N. Mouchtaris" <pmouchta@TELCORDIA.COM>
Subject:      call for papers: VoIP conference
X-To:         iptel@lists.bell-labs.com, sip@lists.bell-labs.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--0__=1wj55wbMuTLaPmr8Vlgwmlg8x6MSQcPhFaLr2uYDP8KJkX3qiio0mrEY
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



Attached is a call for papers for a VoIP conference that is part of SPIE's
Symposium on the convergance of IT and communications (ITCOM 2001).

Feel free to send me an e-mail if you have any questions.

Petros
(See attached file: IT201.pdf)

--0__=1wj55wbMuTLaPmr8Vlgwmlg8x6MSQcPhFaLr2uYDP8KJkX3qiio0mrEY
Content-type: application/pdf;
        name="IT201.pdf"
Content-Disposition: attachment; filename="IT201.pdf"
Content-Description: Adobe Portable Document
Content-Transfer-Encoding: base64

JVBERi0xLjMNJeLjz9MNCjQyIDAgb2JqDTw8IA0vTGluZWFyaXplZCAxIA0vTyA0NCANL0ggWyAx
Mjc0IDM2MSBdIA0vTCA3NzUwNiANL0UgMTYzMDUgDS9OIDIgDS9UIDc2NTQ4IA0+PiANZW5kb2Jq
DSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB4cmVmDTQyIDQyIA0wMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMDExODcgMDAwMDAgbg0KMDAw
MDAwMTYzNSAwMDAwMCBuDQowMDAwMDAxODQyIDAwMDAwIG4NCjAwMDAwMDIwNTkgMDAwMDAgbg0K
MDAwMDAwMzE0NCAwMDAwMCBuDQowMDAwMDAzMzQzIDAwMDAwIG4NCjAwMDAwMDM1NTIgMDAwMDAg
bg0KMDAwMDAwNDY0MSAwMDAwMCBuDQowMDAwMDA0NjYyIDAwMDAwIG4NCjAwMDAwMDUyODMgMDAw
MDAgbg0KMDAwMDAwNTMwNCAwMDAwMCBuDQowMDAwMDA1OTE4IDAwMDAwIG4NCjAwMDAwMDY2MDgg
MDAwMDAgbg0KMDAwMDAwNjgyNiAwMDAwMCBuDQowMDAwMDA2ODQ3IDAwMDAwIG4NCjAwMDAwMDc0
MjcgMDAwMDAgbg0KMDAwMDAwODUyMCAwMDAwMCBuDQowMDAwMDA4NzI5IDAwMDAwIG4NCjAwMDAw
MDg3NTAgMDAwMDAgbg0KMDAwMDAwOTQxNyAwMDAwMCBuDQowMDAwMDA5NDgyIDAwMDAwIG4NCjAw
MDAwMDk4MDIgMDAwMDAgbg0KMDAwMDAxMDQ4MiAwMDAwMCBuDQowMDAwMDEwNjg3IDAwMDAwIG4N
CjAwMDAwMTEzNjggMDAwMDAgbg0KMDAwMDAxMTU2OSAwMDAwMCBuDQowMDAwMDExNzk4IDAwMDAw
IG4NCjAwMDAwMTE5ODIgMDAwMDAgbg0KMDAwMDAxMjY2MyAwMDAwMCBuDQowMDAwMDEyODY5IDAw
MDAwIG4NCjAwMDAwMTI4OTAgMDAwMDAgbg0KMDAwMDAxMzUzMCAwMDAwMCBuDQowMDAwMDEzNTUx
IDAwMDAwIG4NCjAwMDAwMTQyMTcgMDAwMDAgbg0KMDAwMDAxNDIzOCAwMDAwMCBuDQowMDAwMDE0
Nzg5IDAwMDAwIG4NCjAwMDAwMTQ4MTAgMDAwMDAgbg0KMDAwMDAxNTM2MiAwMDAwMCBuDQowMDAw
MDE1NTAxIDAwMDAwIG4NCjAwMDAwMDEyNzQgMDAwMDAgbg0KMDAwMDAwMTYxNCAwMDAwMCBuDQp0
cmFpbGVyDTw8DS9TaXplIDg0DS9JbmZvIDQxIDAgUiANL1Jvb3QgNDMgMCBSIA0vUHJldiA3NjUz
OCANL0lEWzxiZDFmNzYyODY4ZTAwYTQ3NTljN2FkY2VjODE1ZjYzZT48YmQxZjc2Mjg2OGUwMGE0
NzU5YzdhZGNlYzgxNWY2M2U+XQ0+Pg1zdGFydHhyZWYNMA0lJUVPRg0gICAgIA00MyAwIG9iag08
PCANL1R5cGUgL0NhdGFsb2cgDS9QYWdlcyAzMCAwIFIgDS9KVCA0MCAwIFIgDS9QYWdlTGFiZWxz
IDI5IDAgUiANPj4gDWVuZG9iag04MiAwIG9iag08PCAvUyAxMTYgL0wgMjY1IC9GaWx0ZXIgL0Zs
YXRlRGVjb2RlIC9MZW5ndGggODMgMCBSID4+IA1zdHJlYW0NCkiJYmBgYGZgYPnFwMbAIKPAwMuA
ALxAMTYGFgaOHoYnOxgY/AwYUIDurHMsIgo/9zb3e055N//M1tVeBYvXFL/Pff3NgYFBydgFBBqA
6hgFgUBICQSUjS1AJgEBCwND5EUgrQbEdmARUQZ+xhJmAUUHbgXxRm4GBqYIBgZOF5EXPAEMDN2H
JBj2MDBwSTAmCG0IStBj9GLYwriAqUdkAfcEBoZZBxiYWhkYODwYGBQN+A7MY1jV8J05hKmHI4D3
gsGbiQ2Tu54y71TYwtYhdED9+CSGNqHFTFpMDTwaTAfEFsg7IPlIhoFR9SuQZgJib4AAAwCegzwD
DWVuZHN0cmVhbQ1lbmRvYmoNODMgMCBvYmoNMjQ4IA1lbmRvYmoNNDQgMCBvYmoNPDwgDS9UeXBl
IC9QYWdlIA0vUGFyZW50IDMwIDAgUiANL1Jlc291cmNlcyA0NSAwIFIgDS9Db250ZW50cyBbIDUx
IDAgUiA1MyAwIFIgNTcgMCBSIDYxIDAgUiA3MyAwIFIgNzUgMCBSIDc3IDAgUiA3OSAwIFIgXSAN
L01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90
YXRlIDAgDT4+IA1lbmRvYmoNNDUgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1h
Z2VCIF0gDS9Gb250IDw8IC9GMiA0OSAwIFIgL0YzIDQ2IDAgUiAvRjQgNTQgMCBSIC9GNSA1OCAw
IFIgL0Y2IDY5IDAgUiAvRjcgNzAgMCBSIA0vRjggNjQgMCBSIC9GOSA2NiAwIFIgPj4gDS9YT2Jq
ZWN0IDw8IC9JbTEgODEgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgODAgMCBSID4+IA0+PiAN
ZW5kb2JqDTQ2IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1R5cGUxIA0vRmlyc3RD
aGFyIDMyIA0vTGFzdENoYXIgMjU1IA0vV2lkdGhzIFsgMjc4IDI3OCAzNTUgNTU2IDU1NiA4ODkg
NjY3IDE5MSAzMzMgMzMzIDM4OSA1ODQgMjc4IDMzMyAyNzggMjc4IDU1NiANNTU2IDU1NiA1NTYg
NTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgMjc4IDI3OCA1ODQgNTg0IDU4NCA1NTYgMTAxNSANNjY3
IDY2NyA3MjIgNzIyIDY2NyA2MTEgNzc4IDcyMiAyNzggNTAwIDY2NyA1NTYgODMzIDcyMiA3Nzgg
NjY3IA03NzggNzIyIDY2NyA2MTEgNzIyIDY2NyA5NDQgNjY3IDY2NyA2MTEgMjc4IDI3OCAyNzgg
NDY5IDU1NiAzMzMgDTU1NiA1NTYgNTAwIDU1NiA1NTYgMjc4IDU1NiA1NTYgMjIyIDIyMiA1MDAg
MjIyIDgzMyA1NTYgNTU2IDU1NiANNTU2IDMzMyA1MDAgMjc4IDU1NiA1MDAgNzIyIDUwMCA1MDAg
NTAwIDMzNCAyNjAgMzM0IDU4NCAzNTAgMCAzNTAgDTIyMiA1NTYgMzMzIDEwMDAgNTU2IDU1NiAz
MzMgMTAwMCA2NjcgMzMzIDEwMDAgMzUwIDYxMSAzNTAgMzUwIDIyMiANMjIyIDMzMyAzMzMgMzUw
IDU1NiAxMDAwIDMzMyAxMDAwIDUwMCAzMzMgOTQ0IDM1MCA1MDAgNjY3IDI3OCAzMzMgDTU1NiA1
NTYgNTU2IDU1NiAyNjAgNTU2IDMzMyA3MzcgMzcwIDU1NiA1ODQgMzMzIDczNyAzMzMgNDAwIDU4
NCANMzMzIDMzMyAzMzMgNTU2IDUzNyAyNzggMzMzIDMzMyAzNjUgNTU2IDgzNCA4MzQgODM0IDYx
MSA2NjcgNjY3IA02NjcgNjY3IDY2NyA2NjcgMTAwMCA3MjIgNjY3IDY2NyA2NjcgNjY3IDI3OCAy
NzggMjc4IDI3OCA3MjIgNzIyIA03NzggNzc4IDc3OCA3NzggNzc4IDU4NCA3NzggNzIyIDcyMiA3
MjIgNzIyIDY2NyA2NjcgNjExIDU1NiA1NTYgDTU1NiA1NTYgNTU2IDU1NiA4ODkgNTAwIDU1NiA1
NTYgNTU2IDU1NiAyNzggMjc4IDI3OCAyNzggNTU2IDU1NiANNTU2IDU1NiA1NTYgNTU2IDU1NiA1
ODQgNjExIDU1NiA1NTYgNTU2IDU1NiA1MDAgNTU2IDUwMCBdIA0vRW5jb2RpbmcgL1dpbkFuc2lF
bmNvZGluZyANL0Jhc2VGb250IC9IZWx2ZXRpY2EgDS9Gb250RGVzY3JpcHRvciA0NyAwIFIgDT4+
IA1lbmRvYmoNNDcgMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCA3MTgg
DS9DYXBIZWlnaHQgNzE4IA0vRGVzY2VudCAtMjA3IA0vRmxhZ3MgMzIgDS9Gb250QkJveCBbIC0x
NjYgLTIyNSAxMDAwIDkzMSBdIA0vRm9udE5hbWUgL0hlbHZldGljYSANL0l0YWxpY0FuZ2xlIDAg
DS9TdGVtViA4OCANL1hIZWlnaHQgNTIzIA0+PiANZW5kb2JqDTQ4IDAgb2JqDTw8IA0vVHlwZSAv
Rm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgNzE4IA0vQ2FwSGVpZ2h0IDcxOCANL0Rlc2NlbnQgLTIw
NyANL0ZsYWdzIDI2MjE3NiANL0ZvbnRCQm94IFsgLTE3MCAtMjI4IDEwMDMgOTYyIF0gDS9Gb250
TmFtZSAvSGVsdmV0aWNhLUJvbGQgDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgMTQwIA0vWEhlaWdo
dCA1MzIgDT4+IA1lbmRvYmoNNDkgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHlw
ZTEgDS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciAyNTUgDS9XaWR0aHMgWyAyNzggMzMzIDQ3NCA1
NTYgNTU2IDg4OSA3MjIgMjM4IDMzMyAzMzMgMzg5IDU4NCAyNzggMzMzIDI3OCAyNzggNTU2IA01
NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiAzMzMgMzMzIDU4NCA1ODQgNTg0IDYx
MSA5NzUgDTcyMiA3MjIgNzIyIDcyMiA2NjcgNjExIDc3OCA3MjIgMjc4IDU1NiA3MjIgNjExIDgz
MyA3MjIgNzc4IDY2NyANNzc4IDcyMiA2NjcgNjExIDcyMiA2NjcgOTQ0IDY2NyA2NjcgNjExIDMz
MyAyNzggMzMzIDU4NCA1NTYgMzMzIA01NTYgNjExIDU1NiA2MTEgNTU2IDMzMyA2MTEgNjExIDI3
OCAyNzggNTU2IDI3OCA4ODkgNjExIDYxMSA2MTEgDTYxMSAzODkgNTU2IDMzMyA2MTEgNTU2IDc3
OCA1NTYgNTU2IDUwMCAzODkgMjgwIDM4OSA1ODQgMzUwIDAgMzUwIA0yNzggNTU2IDUwMCAxMDAw
IDU1NiA1NTYgMzMzIDEwMDAgNjY3IDMzMyAxMDAwIDM1MCA2MTEgMzUwIDM1MCAyNzggDTI3OCA1
MDAgNTAwIDM1MCA1NTYgMTAwMCAzMzMgMTAwMCA1NTYgMzMzIDk0NCAzNTAgNTAwIDY2NyAyNzgg
MzMzIA01NTYgNTU2IDU1NiA1NTYgMjgwIDU1NiAzMzMgNzM3IDM3MCA1NTYgNTg0IDMzMyA3Mzcg
MzMzIDQwMCA1ODQgDTMzMyAzMzMgMzMzIDYxMSA1NTYgMjc4IDMzMyAzMzMgMzY1IDU1NiA4MzQg
ODM0IDgzNCA2MTEgNzIyIDcyMiANNzIyIDcyMiA3MjIgNzIyIDEwMDAgNzIyIDY2NyA2NjcgNjY3
IDY2NyAyNzggMjc4IDI3OCAyNzggNzIyIDcyMiANNzc4IDc3OCA3NzggNzc4IDc3OCA1ODQgNzc4
IDcyMiA3MjIgNzIyIDcyMiA2NjcgNjY3IDYxMSA1NTYgNTU2IA01NTYgNTU2IDU1NiA1NTYgODg5
IDU1NiA1NTYgNTU2IDU1NiA1NTYgMjc4IDI3OCAyNzggMjc4IDYxMSA2MTEgDTYxMSA2MTEgNjEx
IDYxMSA2MTEgNTg0IDYxMSA2MTEgNjExIDYxMSA2MTEgNTU2IDYxMSA1NTYgXSANL0VuY29kaW5n
IC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNlRm9udCAvSGVsdmV0aWNhLUJvbGQgDS9Gb250RGVzY3Jp
cHRvciA0OCAwIFIgDT4+IA1lbmRvYmoNNTAgMCBvYmoNNTQzIA1lbmRvYmoNNTEgMCBvYmoNPDwg
L0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA1MCAwIFIgPj4gDXN0cmVhbQ0KSIlUU02PmzAQ
vfMr5mhLi4P55lptWqWXbhVu1R7Y4AASsSmbtNpf0r/b8YyJskKCmTdvhvc8sPt21DC8R78jXas0
hwQvjrJCNRUUtSqyRMPpEu0OFw3PLvoZfWmj3dcUNLTnSCcqqbmNoqJSZQNlqRrf1l6iBIYIK0ma
QXuKYh+WBbR/o1/i+HKQpSrE/l87YpAKAwxYyq5m5aC7TgQ7ygImY42PmQpw5NKJeeb6IdNUlQLO
jK/wgwoLz2XWqQvNe5440H16EGDM+pgO8rX9js4zdl5txinISpU0kOcqLdg3OtUaC+xU1ioTL3Q/
yLRUWuwpiWWcqUq0owGpq61m0Zy4ygZD48PVdpxNznYzMXmi89WTjFl5js6J9iFxGbUg4lnGFcbE
xHNYwiAkhz5/kmIG1mOHyXrbdoDpnevQm3565AZhPXBAk6Hr/8g4zTDv7CYIh4QZjxJtUBCEbaNh
NYFsujVgI432Ljrb09M8CCR8Wea7uO2MaE9FrvJGF7if9pk/wDR8gDqtKl6LpTdmAhyJaTDw5xM0
ZaKbnzCDZXQedXbDCZ0uMsfVdShoIMBr5H5nZhOoPl39kmvu99LiTRuKafImvSss779Ik7NCbyn3
H0GCr8KR+FOK0brZDZM/Lp8CMGlk0upuwwgTYxvlIgu/MsMoCg6FJ8rB9LcwuwsMZ2FZ3bB23PmZ
7o0utzc6+M9Ngafk638BBgC/Ugr4DWVuZHN0cmVhbQ1lbmRvYmoNNTIgMCBvYmoNNTM2IA1lbmRv
YmoNNTMgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA1MiAwIFIgPj4gDXN0
cmVhbQ0KSIl8k8lu2zAQhu96ijmSB7HkcJF0TN0UcIAiBkL0EvcguLSjwpYCO06R1+ihz9vh4sQJ
jMIHc7Zvfg5H/qa69pWCASprhOzAWdFasKhE20KthWlhH6r1KSqFbS5ElWxjGJURqgGKQt3YSyHd
2VQaUzJXYvT/p1IZKboLlSQFNlSfhCHlth1YgecApYUmqO6EtK+AlJPin3316asBBZ5ynbAOJP3y
SbuIbai30uB3laReUkgpDfhVVccj+X9X92zuZ7ffOOl3jGRIxX/4G+Lqwm2ERLqZBP8lAdQbwEQA
m/XbLaynPSz6x7A/QD/+hKtxnI7jKuzC+MT9L8JhxiEK2SaZ+dQ50WloaIi2kSoKTWSFsclJb1T5
fRpWAW6fwx7mC1iSPV8sOfiwehin7bR54UoJzSgy9yjVkpdr2HINJYiUxpNOeTzOYRlP6orlZkqV
0dwt5rx2NJjrPxwN4Q9QHCOnPM2eshWytSeLjX1xDtPYb+HuZRe9j9NhOKYTTFzR0xMh/YGPwpE9
ZDMU74zT21v2PveZ18hC6rIJNF2Y1rnVB1XFO52pSq37d6IHjjFpfJvhEPLrzabda81xHFb9h4rD
+xUxhj659mxFbHsaJK11nmR6l1m8hmG0bagJVN6oPtXTp6EsYqTkJXCnJXCYKSj/ooGr44bXRGrZ
kVMPdkjyMG8vFG0ua2tFZ50t0gj3T4ABAHQ48MINZW5kc3RyZWFtDWVuZG9iag01NCAwIG9iag08
PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UeXBlMSANL0ZpcnN0Q2hhciAzMiANL0xhc3RDaGFy
IDE4MSANL1dpZHRocyBbIDI3OCAzMzMgNDc0IDU1NiA1NTYgODg5IDcyMiAyMzggMzMzIDMzMyAz
ODkgNTg0IDI3OCAzMzMgMjc4IDI3OCA1NTYgDTU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1
NTYgNTU2IDMzMyAzMzMgNTg0IDU4NCA1ODQgNjExIDk3NSANNzIyIDcyMiA3MjIgNzIyIDY2NyA2
MTEgNzc4IDcyMiAyNzggNTU2IDcyMiA2MTEgODMzIDcyMiA3NzggNjY3IA03NzggNzIyIDY2NyA2
MTEgNzIyIDY2NyA5NDQgNjY3IDY2NyA2MTEgMzMzIDI3OCAzMzMgNTg0IDU1NiAzMzMgDTU1NiA2
MTEgNTU2IDYxMSA1NTYgMzMzIDYxMSA2MTEgMjc4IDI3OCA1NTYgMjc4IDg4OSA2MTEgNjExIDYx
MSANNjExIDM4OSA1NTYgMzMzIDYxMSA1NTYgNzc4IDU1NiA1NTYgNTAwIDM4OSAyODAgMzg5IDU4
NCAwIDAgMCAwIA0wIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDU1NiANNTU2IDAgMCAwIDAgMCA3MzcgMCAwIDAgMCAwIDAgMCA1ODQg
MCAwIDAgNjExIF0gDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nIA0vQmFzZUZvbnQgL0hlbHZl
dGljYS1Cb2xkT2JsaXF1ZSANL0ZvbnREZXNjcmlwdG9yIDU1IDAgUiANPj4gDWVuZG9iag01NSAw
IG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50IDcxOCANL0NhcEhlaWdodCA3
MTggDS9EZXNjZW50IC0yMDcgDS9GbGFncyAyNjIyNDAgDS9Gb250QkJveCBbIC0xNzQgLTIyOCAx
MTE0IDk2MiBdIA0vRm9udE5hbWUgL0hlbHZldGljYS1Cb2xkT2JsaXF1ZSANL0l0YWxpY0FuZ2xl
IC0xMiANL1N0ZW1WIDE0MCANL1hIZWlnaHQgNTMyIA0+PiANZW5kb2JqDTU2IDAgb2JqDTUwMiAN
ZW5kb2JqDTU3IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggNTYgMCBSID4+
IA1zdHJlYW0NCkiJjJNNj9MwEIbFNb9iTsiRGuOPxB+7p1XLIgErVhBOLAeTuq2hTaSkuyv+PXbt
ZNvAgdOMv+Z95s0kI1A/Z+hVXv/M3txyoFBvMoKF4OBPVllBMCGMQ91kIRM6XP+GYNntuz4vBObI
rDu/bJ9yhQWy7THsauS6FpbTyqa7APn3+r1XElGJclwqTaMWOan8D48YeSRLPCt7AuBJSaBFXkjM
zkDFCfTrl5tEIBMB84UJ+MAFJhoEY1hUUB/OcXx7G9vbtrGw3BnXX0U8FUtIXLFIhyAe6JGbVeng
3h77boC77rHZHU3vhsVFCYXpeBNqu2+6fu2Mz5pd6/m3zg7xeoIuaIU1g4LhcjKFVMkUGbJgyn3f
bXtz8BYcDu54tPYqtT6JVvov5+cd8NTaSWKcA6FllLjdW1+73cJNu/YuV1giG4PJC+3DkBeUvOy2
fsl9XFySaFypMxk5yfBx3NzQdNfj8CQ4js/ZyumRiI9WznftnYYP5ofbm80vMyzmBqh/TZVkqQJ8
qt/C50Au0Ou8KH1YwQN611vb2If8Om7NqDSm5QsWnSxTo2V+Ah7b6A58dO2MqeAa+2EvKA5/3fht
WagSUqlVLDNNSU4pVuhiVuZGaazYWaOEhmreIPPk1nDXrH4PZo4hMeFzc8NjFdLnPwIMABOT/1YN
ZW5kc3RyZWFtDWVuZG9iag01OCAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UeXBl
MSANL0ZpcnN0Q2hhciAzMiANL0xhc3RDaGFyIDI1NSANL1dpZHRocyBbIDI3OCAyNzggMzU1IDU1
NiA1NTYgODg5IDY2NyAxOTEgMzMzIDMzMyAzODkgNTg0IDI3OCAzMzMgMjc4IDI3OCA1NTYgDTU1
NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDI3OCAyNzggNTg0IDU4NCA1ODQgNTU2
IDEwMTUgDTY2NyA2NjcgNzIyIDcyMiA2NjcgNjExIDc3OCA3MjIgMjc4IDUwMCA2NjcgNTU2IDgz
MyA3MjIgNzc4IDY2NyANNzc4IDcyMiA2NjcgNjExIDcyMiA2NjcgOTQ0IDY2NyA2NjcgNjExIDI3
OCAyNzggMjc4IDQ2OSA1NTYgMzMzIA01NTYgNTU2IDUwMCA1NTYgNTU2IDI3OCA1NTYgNTU2IDIy
MiAyMjIgNTAwIDIyMiA4MzMgNTU2IDU1NiA1NTYgDTU1NiAzMzMgNTAwIDI3OCA1NTYgNTAwIDcy
MiA1MDAgNTAwIDUwMCAzMzQgMjYwIDMzNCA1ODQgMzUwIDAgMzUwIA0yMjIgNTU2IDMzMyAxMDAw
IDU1NiA1NTYgMzMzIDEwMDAgNjY3IDMzMyAxMDAwIDM1MCA2MTEgMzUwIDM1MCAyMjIgDTIyMiAz
MzMgMzMzIDM1MCA1NTYgMTAwMCAzMzMgMTAwMCA1MDAgMzMzIDk0NCAzNTAgNTAwIDY2NyAyNzgg
MzMzIA01NTYgNTU2IDU1NiA1NTYgMjYwIDU1NiAzMzMgNzM3IDM3MCA1NTYgNTg0IDMzMyA3Mzcg
MzMzIDQwMCA1ODQgDTMzMyAzMzMgMzMzIDU1NiA1MzcgMjc4IDMzMyAzMzMgMzY1IDU1NiA4MzQg
ODM0IDgzNCA2MTEgNjY3IDY2NyANNjY3IDY2NyA2NjcgNjY3IDEwMDAgNzIyIDY2NyA2NjcgNjY3
IDY2NyAyNzggMjc4IDI3OCAyNzggNzIyIDcyMiANNzc4IDc3OCA3NzggNzc4IDc3OCA1ODQgNzc4
IDcyMiA3MjIgNzIyIDcyMiA2NjcgNjY3IDYxMSA1NTYgNTU2IA01NTYgNTU2IDU1NiA1NTYgODg5
IDUwMCA1NTYgNTU2IDU1NiA1NTYgMjc4IDI3OCAyNzggMjc4IDU1NiA1NTYgDTU1NiA1NTYgNTU2
IDU1NiA1NTYgNTg0IDYxMSA1NTYgNTU2IDU1NiA1NTYgNTAwIDU1NiA1MDAgXSANL0VuY29kaW5n
IC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNlRm9udCAvSGVsdmV0aWNhLU9ibGlxdWUgDS9Gb250RGVz
Y3JpcHRvciA1OSAwIFIgDT4+IA1lbmRvYmoNNTkgMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVzY3Jp
cHRvciANL0FzY2VudCA3MTggDS9DYXBIZWlnaHQgNzE4IA0vRGVzY2VudCAtMjA3IA0vRmxhZ3Mg
OTYgDS9Gb250QkJveCBbIC0xNzAgLTIyNSAxMTE2IDkzMSBdIA0vRm9udE5hbWUgL0hlbHZldGlj
YS1PYmxpcXVlIA0vSXRhbGljQW5nbGUgLTEyIA0vU3RlbVYgODggDS9YSGVpZ2h0IDUyMyANPj4g
DWVuZG9iag02MCAwIG9iag01ODkgDWVuZG9iag02MSAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURl
Y29kZSAvTGVuZ3RoIDYwIDAgUiA+PiANc3RyZWFtDQpIiVxSwW7bMAy95yt4lIdakxLXTrDjhgEd
MKBbjfbQ7qDJdK3WlgpJTta/H2U7aZuDLVIiHx8fubpncOd833x1wxfI/tQ/Vp+/70BC3a4uuZQg
oP62ElwIUUKtVzmZu2QeVvfsBkOnGm+yvOQFg5+uU/ZiwdjOGBVfv0HI4gSRzAQBVHeP2SXl+6yg
f5idcy4FL8sZKJ/IbI5I1a6aka4xehcyKXiVqIy6i8qbcMZnSxkLoYQgUi6DrH56KyW4XELYb/VE
LabXvFhzajuXfL2ZnmrVv6gGL+bUBX3Dq4Ulgxp77XxjFFm6s653jwbDhDWF5Wu+rk4NkdKJDpdF
slI/dYegnd2jf0SrEVwLxrbOD1kuN1wyFY2zoGxDUcMwWqOnm6ldkYjKatG9WBBjymTvyECnAqi+
dwdsIFK9MUx1GhUVWIwH558DtFm+ZY5yJY0oodefliFsF84yWamCa1v0xj6mKawZ7J0h4oniMPbR
DJjUCOj3dB043HVo4TbFfIQ9bUm5WxbNkQpZyUualBTs6no6Htitu7p+yCbnQJ20xodIItEeNKPG
WRj02lCLr3Q/BVKbx2qCF1ux7OFgmtwa6jnJYiIkvEH5Z4yEk1SyBID/XnDedRvM/h2OKI84qo/o
LU2CnkkEYhwdRK8ak4ajeojY40vnLM5CkKxrwtPI4deoehNfaQAf5Dhtxu64GTezglnFd2wial0E
AhJMZXlFqzE7enY8jY8Os6xNXE7y06GJkglhRPiLWqX50+cDHNCfTYW2Sf8XYABqBCTkDWVuZHN0
cmVhbQ1lbmRvYmoNNjIgMCBvYmoNPDwgDS9UeXBlIC9FbmNvZGluZyANL0RpZmZlcmVuY2VzIFsg
MSAvRzQgXSANPj4gDWVuZG9iag02MyAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVu
Z3RoIDIyOSAvU3VidHlwZSAvVHlwZTFDID4+IA1zdHJlYW0NCkiJYmRgYWJgZGRUcHV1c3V00Q4P
0AupLMhPL0osyMhMDq7MTcrPKTawNAKpsfwhw/RDlvmHKMtvSR7m+TwsP+R4xLp/V8qwrPl5mFVu
AeP/7m4IycP+PVngexr/90zB7u9rhRhYGBmZTTwT3U18E5OL8nNTUzIT493y80og9qQWxZvoGcaH
B8RjWo1DEIcjGRgYWRgY2xmYgPbZd/P91P5x9vsTUfeSoJg4udjYwBL3Hs+u4EUxOzlidhUfOid1
dtHRnTvldu46uuhcz8WuIyU74zh2xi4KcpfqZucDCDAARdRnOAplbmRzdHJlYW0NZW5kb2JqDTY0
IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1R5cGUxIA0vRmlyc3RDaGFyIDMyIA0v
TGFzdENoYXIgMTgxIA0vV2lkdGhzIFsgMjUwIDMzMyA0MDggNTAwIDUwMCA4MzMgNzc4IDE4MCAz
MzMgMzMzIDUwMCA1NjQgMjUwIDMzMyAyNTAgMjc4IDUwMCANNTAwIDUwMCA1MDAgNTAwIDUwMCA1
MDAgNTAwIDUwMCA1MDAgMjc4IDI3OCA1NjQgNTY0IDU2NCA0NDQgOTIxIA03MjIgNjY3IDY2NyA3
MjIgNjExIDU1NiA3MjIgNzIyIDMzMyAzODkgNzIyIDYxMSA4ODkgNzIyIDcyMiA1NTYgDTcyMiA2
NjcgNTU2IDYxMSA3MjIgNzIyIDk0NCA3MjIgNzIyIDYxMSAzMzMgMjc4IDMzMyA0NjkgNTAwIDMz
MyANNDQ0IDUwMCA0NDQgNTAwIDQ0NCAzMzMgNTAwIDUwMCAyNzggMjc4IDUwMCAyNzggNzc4IDUw
MCA1MDAgNTAwIA01MDAgMzMzIDM4OSAyNzggNTAwIDUwMCA3MjIgNTAwIDUwMCA0NDQgNDgwIDIw
MCA0ODAgNTQxIDAgMCAwIDAgDTAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTAwIA01MDAgMCAwIDAgMCAwIDc2MCAwIDAgMCAwIDAg
MCAwIDU2NCAwIDAgMCA1MDAgXSANL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNlRm9u
dCAvVGltZXMtUm9tYW4gDS9Gb250RGVzY3JpcHRvciA2NyAwIFIgDT4+IA1lbmRvYmoNNjUgMCBv
YmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCA2OTkgDS9DYXBIZWlnaHQgNjc2
IA0vRGVzY2VudCAtMjA1IA0vRmxhZ3MgMjYyMTc4IA0vRm9udEJCb3ggWyAtMTY4IC0yMTggMTAw
MCA5MzUgXSANL0ZvbnROYW1lIC9UaW1lcy1Cb2xkIA0vSXRhbGljQW5nbGUgMCANL1N0ZW1WIDEz
OSANL1hIZWlnaHQgNDYxIA0+PiANZW5kb2JqDTY2IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1
YnR5cGUgL1R5cGUxIA0vRmlyc3RDaGFyIDMyIA0vTGFzdENoYXIgMTgxIA0vV2lkdGhzIFsgMjUw
IDMzMyA1NTUgNTAwIDUwMCAxMDAwIDgzMyAyNzggMzMzIDMzMyA1MDAgNTcwIDI1MCAzMzMgMjUw
IDI3OCANNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDMzMyAzMzMgNTcw
IDU3MCA1NzAgNTAwIA05MzAgNzIyIDY2NyA3MjIgNzIyIDY2NyA2MTEgNzc4IDc3OCAzODkgNTAw
IDc3OCA2NjcgOTQ0IDcyMiA3NzggDTYxMSA3NzggNzIyIDU1NiA2NjcgNzIyIDcyMiAxMDAwIDcy
MiA3MjIgNjY3IDMzMyAyNzggMzMzIDU4MSA1MDAgDTMzMyA1MDAgNTU2IDQ0NCA1NTYgNDQ0IDMz
MyA1MDAgNTU2IDI3OCAzMzMgNTU2IDI3OCA4MzMgNTU2IDUwMCANNTU2IDU1NiA0NDQgMzg5IDMz
MyA1NTYgNTAwIDcyMiA1MDAgNTAwIDQ0NCAzOTQgMjIwIDM5NCA1MjAgMCAwIA0wIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgDTAg
NTAwIDUwMCAwIDAgMCAwIDAgNzQ3IDAgMCAwIDAgMCAwIDAgNTcwIDAgMCAwIDU1NiBdIA0vRW5j
b2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0Jhc2VGb250IC9UaW1lcy1Cb2xkIA0vRm9udERlc2Ny
aXB0b3IgNjUgMCBSIA0+PiANZW5kb2JqDTY3IDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0
b3IgDS9Bc2NlbnQgNjk5IA0vQ2FwSGVpZ2h0IDY2MiANL0Rlc2NlbnQgLTIxNyANL0ZsYWdzIDM0
IA0vRm9udEJCb3ggWyAtMTY4IC0yMTggMTAwMCA4OTggXSANL0ZvbnROYW1lIC9UaW1lcy1Sb21h
biANL0l0YWxpY0FuZ2xlIDAgDS9TdGVtViA4NCANL1hIZWlnaHQgNDUwIA0+PiANZW5kb2JqDTY4
IDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgMCANL0NhcEhlaWdodCAw
IA0vRGVzY2VudCAwIA0vRmxhZ3MgNCANL0ZvbnRCQm94IFsgMCAtMjI5IDExOTYgODE1IF0gDS9G
b250TmFtZSAvRUVGRUFEK1dQLlR5cG9ncmFwaGljU3ltYm9sczA5MiANL0l0YWxpY0FuZ2xlIDAg
DS9TdGVtViAwIA0vQ2hhclNldCAoL0c0KQ0vRm9udEZpbGUzIDYzIDAgUiANPj4gDWVuZG9iag02
OSAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UeXBlMSANL0ZpcnN0Q2hhciAxIA0v
TGFzdENoYXIgMSANL1dpZHRocyBbIDY2MyBdIA0vRW5jb2RpbmcgNjIgMCBSIA0vQmFzZUZvbnQg
L0VFRkVBRCtXUC5UeXBvZ3JhcGhpY1N5bWJvbHMwOTIgDS9Gb250RGVzY3JpcHRvciA2OCAwIFIg
DT4+IA1lbmRvYmoNNzAgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHlwZTEgDS9G
aXJzdENoYXIgMzIgDS9MYXN0Q2hhciAxODEgDS9XaWR0aHMgWyAyNTAgMzMzIDQyMCA1MDAgNTAw
IDgzMyA3NzggMjE0IDMzMyAzMzMgNTAwIDY3NSAyNTAgMzMzIDI1MCAyNzggNTAwIA01MDAgNTAw
IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAzMzMgMzMzIDY3NSA2NzUgNjc1IDUwMCA5MjAg
DTYxMSA2MTEgNjY3IDcyMiA2MTEgNjExIDcyMiA3MjIgMzMzIDQ0NCA2NjcgNTU2IDgzMyA2Njcg
NzIyIDYxMSANNzIyIDYxMSA1MDAgNTU2IDcyMiA2MTEgODMzIDYxMSA1NTYgNTU2IDM4OSAyNzgg
Mzg5IDQyMiA1MDAgMzMzIA01MDAgNTAwIDQ0NCA1MDAgNDQ0IDI3OCA1MDAgNTAwIDI3OCAyNzgg
NDQ0IDI3OCA3MjIgNTAwIDUwMCA1MDAgDTUwMCAzODkgMzg5IDI3OCA1MDAgNDQ0IDY2NyA0NDQg
NDQ0IDM4OSA0MDAgMjc1IDQwMCA1NDEgMCAwIDAgMCANMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg
MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1MDAgDTUwMCAwIDAgMCAwIDAg
NzYwIDAgMCAwIDAgMCAwIDAgNjc1IDAgMCAwIDUwMCBdIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNv
ZGluZyANL0Jhc2VGb250IC9UaW1lcy1JdGFsaWMgDS9Gb250RGVzY3JpcHRvciA3MSAwIFIgDT4+
IA1lbmRvYmoNNzEgMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCA2OTkg
DS9DYXBIZWlnaHQgNjUzIA0vRGVzY2VudCAtMjA1IA0vRmxhZ3MgOTggDS9Gb250QkJveCBbIC0x
NjkgLTIxNyAxMDEwIDg4MyBdIA0vRm9udE5hbWUgL1RpbWVzLUl0YWxpYyANL0l0YWxpY0FuZ2xl
IC0xNS41IA0vU3RlbVYgNzYgDS9YSGVpZ2h0IDQ0MSANPj4gDWVuZG9iag03MiAwIG9iag01NjIg
DWVuZG9iag03MyAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDcyIDAgUiA+
PiANc3RyZWFtDQpIiWxTsbKbMBDs/RVXQsbWgHl52GVm0iSTIgWTJvMKGc6gRJYcSTbh73MngR1m
XqUTSLt3u6vNrhBFfaygGTc/s1FprUyf715FnUGwkO/KIgtWo5MB007bEf7cpFZhghO28uYR7BnC
gMC/WusD7fO35uum+bBh+KI4QtNuElOZmPi4R3dXLQpobCenLWjpeiIhjlY6p9B5GFUYQBKw6SE4
2amgrAFl1vA1wxeirrhidHs+o+NBykJUGQyqHx49z6wepEPq1njVpbMzZJHAio8JqsOrttOFRt9n
SMJkJmkSPyRFaPof9st3AZ+0t9tYwyA9dU1SqOAfuqy7PsxEJVdMJa9XlDo/CgJelL262CsL7PJd
LQ6ZZHcOWcfUtEZFpIaAGq+DNQ9Z/f9s1XGfOAZ5x7xmhs5Z4utolRcZVCu1ngR8i0qju6TR/K0l
JL+a8yGUKF+X1jk4QFKhmdta2ptvGhgHJM9dUsdgGK377aGVhka0d/JgJU65XxLzepgpViZK08W7
JwRSqYOzdbCYTnkZCY/8dXJ6P4qcRK4YF/+2pCFdewQjDDIwurGBCSIucZymZwTJplVcGCp7WrDM
JyBvftHf3V5UL9B8Xue1qpe8NvQaeksuxoekSBcb9atT2mg9s/l1TCAtbt6ZFoFO00M9xcmD7aPK
sTmiLUVZP2n38+ixYlqHHqVr6YLfAppeGeRHx+KSqs7nL3W0MHnPS3QvYDsYq22v0G/zt38CDAAQ
7kH1DWVuZHN0cmVhbQ1lbmRvYmoNNzQgMCBvYmoNNTg4IA1lbmRvYmoNNzUgMCBvYmoNPDwgL0Zp
bHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA3NCAwIFIgPj4gDXN0cmVhbQ0KSIl0U8Fu2zAMxa75
CqIne6hdO47jZLdu3YAOGLChxi7DDooiR9xkKZPkpPn7UpabtMN2CR8j8/GJfGo/z9q3s6zIi6Is
oeUzQquAjrMfyRG9BAad4YMDo0GaI3BmLQrrCGhIs7JIDP2WeZl0aba6BJFmDQUbMxCPHD3qHXw3
91/Tn+3Ythgbhl6JE/aAXDgAL5mHvTUH3AqQuJPwZ2AK/QlMB9Nn4A0MhF2etr9m8yqf1zBf5HUD
7V28TFEH7gCX6zreppVIqo3uhBWaOCjbM+sDrZcC7tsPpu/h4dTvjcOhB6a3o9ACMrreC+p1nFO9
Digwf3yUuEF/DUeJXMZ5iXFigZhaHoTdjT1N93z3SFVFqmoVUKBC3RnbM49UTAKouO8HjTz+4wWX
2iizQ+FyaKU4T5LIqomsqZdNJHNhB01ySrMlhT6sokmm26W0uWNa51WCSo2ZZ2lD6W8B+1igYgEL
s4pQxwPwMZUxFbCZABsimM6nKnJERWF4Zn01gUUUXVYBBdF3Iozr5r0Z1FbYtJznywSYFaF6kbAY
roPzKAZ3MueznuxC5hrtch7S6R8+44bsuzUWmHKGPKyU2MLVAyqkNcEXM2jPUOdXEIxFm5/n1eKy
+erZVNV6GvHt4KWh1xAGSCLHiPqAnmjHoRpww6ZHD2zjvGXcO8Doi84oZY4k+2+XvZAbLGCFYoHO
mz1y9y4Iu/m0BHqj3UuFyZt4sppOcnJBMR6EJwe3lktSxf1ghXvFkY2fnrv/n+fb5R0+TO+QPn0S
YACr0S4YDWVuZHN0cmVhbQ1lbmRvYmoNNzYgMCBvYmoNNDczIA1lbmRvYmoNNzcgMCBvYmoNPDwg
L0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA3NiAwIFIgPj4gDXN0cmVhbQ0KSImkU02P2jAQ
Va/8ijnG1eK1Q/hIb0gIiapaoSXqpduDY4bg1tjIMcvy7+uPpdrLtiq9jGcy0Xtvxs+D++UEODS7
wZDRyRSGnPIpNItB8YE0Pwb3y1nupiZLjUfUSrRKK3+5g0fsQ4ZGhlyYLSzFSXtorEYnjMSM8a8M
X+1qDRt0z0pin2D7XMB8vepvwgz/McZKaGRKJ/UMmvPgW6Y62DxOoiJDzgplPHZOeGUNnJXfh+BQ
Y9+DQX+27mdPvjef35XBIg+LDH8RxK+C6rrOglaB2UUGZTrCGa0LsDtIMpOQ9aZ5AGWkPm0VmYa2
IXWIXYqwIrz8/c2nPhI+CodORY6KDEvKiw6NT2O8rx7g4Trv2603H/9wexvVGaGDfDg66620uoed
dWmG2/ww325d2H2EjDdkTocWXaqOgULIPf4vQ9qvfUYHQsp4zR7l3lhtOxWwnwqkHYWXxebLHUjR
anwit/Es8Kjt5RAWD/hyDEOEl/Nq8egua/pwCmdwmxHKjMAryqoAwSBnfFZFKl5XdDqKJjq8NXjM
qlG205yUNR0XLamK3jshPSxOCAvh8ROZFQEBlti6k3AXMqpoVUAZTJlMwWhVj9NQbBxfy9Wywafy
lwADAEZHFYkNZW5kc3RyZWFtDWVuZG9iag03OCAwIG9iag00NzQgDWVuZG9iag03OSAwIG9iag08
PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDc4IDAgUiA+PiANc3RyZWFtDQpIiWxTW2/a
MBR+9684j/ZDPN9iJ3srJNU2rV0FYdI07SGkps2UQsVl1f79jh2DOkARsXMu/i7HEMGFyKF5Iz/p
Hcuk4ZK2LBM8p+vDrtv2r3uoDh6qdu8/Msc1BVXAWeVfpjV3mBFCsl/NF/LhNgcJzYpIyYUBgc+4
k9JyhTlbcFEKLHkhWWCgcNuRsLNuJPOwZZlFiE3n/WO/ftrBZhUiCLMf1+cAbmi/g26zTjmfuvy6
8/DGsiIUDAMsPbwelkO/e/aP0K7x96fth3Y5eGj3Z8d6eEmH+BRCeJ50qVGX41aWFjIUZXMFTUVE
FBC404Y1v0nBiyIKjxslLC8dyNxyrd/pznVoo59qCD3nbikludP/dUUYenMFQZVclVcQbHJWSjM6
O5k3OD6cA50xge8bphwu0/hxTEGK3lcQlV9QK/NzuHcO3F3y08LwXF/hZ0781MgvIht6v5hPZ5+R
jkQaD5EXhWpRQ5UKxlA9HwlmjjsndBiJVkaHkcTzTXk8X7jTNVcaL/ICBZc0mpHjJYZJDaePCCxw
9NNj5OsPJjWiwreUmYzt9ex7XV21SDsdFRsU7i4s4sGiuiHa4j8BHC5Ym+syeJVpbmHrySplbYEW
lpfZfwIMAES80PYNZW5kc3RyZWFtDWVuZG9iag04MCAwIG9iag08PCANL1R5cGUgL0V4dEdTdGF0
ZSANL1NBIGZhbHNlIA0vU00gMC4wMiANL09QIGZhbHNlIA0vb3AgZmFsc2UgDS9PUE0gMSANL0JH
MiAvRGVmYXVsdCANL1VDUjIgL0RlZmF1bHQgDS9UUjIgL0RlZmF1bHQgDT4+IA1lbmRvYmoNODEg
MCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxNTIgL0hlaWdo
dCAxNTIgL0JpdHNQZXJDb21wb25lbnQgMSANL0NvbG9yU3BhY2UgL0RldmljZUdyYXkgL0xlbmd0
aCA0MzkgL0ZpbHRlciAvQ0NJVFRGYXhEZWNvZGUgL0RlY29kZVBhcm1zIDw8IC9LIC0xIC9Db2x1
bW5zIDE1MiA+PiA+PiANc3RyZWFtDQr5MgaZVQV5BQK5KgPciwHh5EgPDZBA4IHBEFdBDY4cEQ21
YTIFwYIgYsgg2ocKGEDTBwkwQ3BWEgcKMOEyTB4dSXAvDhQRBp1DqCDYdFRCBt8MIJhkNOO2gg2F
4YaCDYQXDBpBsILsNJsJdhoIg4gjtsEFww0r2wS2w0vbCC7JA17ZGRwzpr3BBdipwJ2K7W+12q9r
hr9hLa/a7X9d/2thr9r1/X/yEm16Ja/ktbWq/7+v/9pf+3+fDH5mGP4X8E2tL////+//39f/fX/9
f//v7//+vv6nQUfNAYa1h/BygLYX/h8F/76/9rUhn+F17w84DfOBsX/+lh/+C2H/4Lg//rf/rd/6
r////+//1v/1u/9V//71/1tkdXzqKt/9/v/pb/67t/6W4+Kq79Lv/tv0l3+rf0vfqrb9Lt+krv12
36S2/SVt+ltutJdtNJK2xFdsMIJYbSVsMJbYYSWwwkrDBhLbBkM1OrkQGyuUglWhe5JermcCDq6B
gnXRDpA0rYRDPWKsQZOGnbhXq63q3V6vV0r1eFb71eFDpXq9Xq8KHq3V0FD1eFD1eFeoeFDEK1DC
j+ACACAKZW5kc3RyZWFtDWVuZG9iag0xIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAz
MCAwIFIgDS9SZXNvdXJjZXMgMiAwIFIgDS9Db250ZW50cyAzIDAgUiANL01lZGlhQm94IFsgMCAw
IDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRv
YmoNMiAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9GMiA0OSAw
IFIgL0YzIDQ2IDAgUiAvRjUgNTggMCBSIC9GNiA2OSAwIFIgL0YxMCA0IDAgUiAvRjExIDUgMCBS
IA0vRjEyIDYgMCBSIC9GMTMgNyAwIFIgL0YxNCA4IDAgUiAvRjE1IDkgMCBSID4+IA0vRXh0R1N0
YXRlIDw8IC9HUzEgODAgMCBSID4+IA0+PiANZW5kb2JqDTMgMCBvYmoNPDwgL0xlbmd0aCA2Nzcz
IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJlFf9U9vMEZ6Q2LKxxwJj4yTQ9Jp+
zKkTK7o7fea3ACZxS4AB87aZ0B+EEUFvwWZsk7f5N/oXd/fuJMuEJHQYLOlOe/fc7rPPrhzyefn1
u2NGPk+XGUnJshC2F5BAcJsz4tihS7oes92QTJLli8VZT3h2xElXviWnPT+0g59Z+yHDy7fWgtm+
B8auzURm7NmC3zPricgO/IWtA8f2o59Y+0GEl2+ttwbLr3cFYWRwsRwRB/4i4ro2BxPG4OLAzPWy
YzuOSwbDZYcMflumzLYGv4IdV3YMlpOm8sYL5YZFa7Ts4hoOR/tP9Phk60N/YDFGifw9sByb0zfW
vwZ/y1EwDv5jdxeC3YnanDlqd7DE3Qc7y/TR0uMnpbKxAI7bkesH6gUJQchzwB0LFBjywer6dgAg
PHqy/X7w1mKe7dMji9uC9o8lqNxHXYATki5M+dmKBcfwO46xfbWxOryf7cz9uRusbgCb9QekB/u6
AGP7PdF3WxZ4gB4PjrKZARkckIP9noTUGyyzCA4fgcdDOwJ8EQYdtvLz0Ga+5A7EHcgD7ztM+VJC
YjyDJLjy7fbB/m7vqLe/3cOTdBk4JgT3dSEI+UHE/MSf6MH+ntX1AN3HDJUigBeEyEfuSkLeByoU
tg+5BMzkrECULL7ibnil58I5l0IF4JdxOkzIgRXYHv1iRfCbTEj/kJzCTP/w1EKGCTukiYWHoMPL
0fhq/PmrRNt1AaoQGE+P3xNP8XOie55ve+J+mr+1OIcodpHcx5LoR3Jou0D9vqS+vN3DNxntLTJu
MSsBLXrt25x0HwA1t1Uo2RwwywEzO6InCEQgKAee3qungyOy1z/WY/39d/ejZG5kR8EdmILnOzHN
s1N6M0lHw/QmviLx7exyPCEX6WQ6O7UU78ARruIdQ/5l1GMSKN2F1+OrzHKKJnPiwRFC5N93iceA
1cg8Dtog5gIn/DlKnaBvyC6CArSf0y94ckGTEVBqFF8nMJiO0lkaX03JaDxTfPJt15WgBbAKQH+i
8XCY3Mzis6vk1HpF9mK52kV8nV59xQU51cu9Im8vLtKrNJ6l49Er0CQuYDJG33sUxkef5Q6Dvyqs
0RxrpLDG5+eTZDp9hbRyIUSJYtNVcnM5HsHyu/F/cM2IvrIwxiQenZPedZyCF5WlrY6AogX54Ebq
BHdo5v2cZm4INlFBZRwZ/k/08Kh33NuXDAoV1UKqn/oH+/fzSS/pR1ALCqES8+MLdfz+6DwdxrOE
oFvp+HZCbibJRTJJRqAOF8CXlwdWSCdAt0M4bDKaSUe/JOOJ3NgpRu1eNtCXh+PpDLSlaG+/BIaM
YNGbq3iYXMMwSadkenv2azKckdkYnaVD5s6TgGt9GF7GQK//WgJVi5yn0+Ekkas+JBL+AyLBQZsC
5yEpv6WSPMvvIz28rZ+Jvvb+OfhhnKByhlEepblYMy3Wb29uJmPJw5Cm1xAulQVweqjx5DcLahij
Y6WYk/OHUTL4uSNEJGzXy3ApL3yif+99BNmFzf+RKdzO8Y9OJ0IOTV6hI/o2onsp5HdMrjHXQK9p
qvL3+vaajC9A4b4oNyZS9Mm/k6/qWR7co+OHHjl8wJF9ONJ36tLWUb+3S7b6B+9UPTq08PjvP35H
0r0I8rm4YN4DqNi6maSTXNNf36gkAdnSIp0JO2SZX5T1/5so3+cJlADodqEh8qEX9rJeWPDQ9vy8
GZ5Pc9+zoYkoNMM88mTv+mNz4fjYcN9nDvKPyzv4EeDKbgzN/ewrwMOyIxwP6xOaw7ybN+qyE8+a
WuhYHB1SeQemwLsAiqsbFXol3YNVqqdQWGt1+PXwv94wDQt7ssaKuq7iPM4011rtJt6o8ZXGmrpZ
gl9B1zvq6alybMN81ll73jHbncXVHsGvS031EixRazXzHdVCnfa62dhoPK935nu1zE29eqNWq5r1
trTCeRk8Bu0iKjxQA0ggSU9x8ne1Fw15pmptoS/sssAOXCENwtCZcynIuQShVFw6m84sUEI6gV8X
airWxaEaIju3CdmJ1UMiZ97oNNDJFdrQiETzFrRQGHxXf0FADd5NzibQgwp6G6vrV0vgVwX03g5b
TCwQSZARv7Dkt5ih/qN349EtFAUJOwXnefRGQnwodvjoC8Ii9nnW+loLCLTUH2IJ1lsA6+XaAi2N
Fhe4Y5CSoAaB4+i2tzs/QbF1OpyMh1YX+EqT5BxkYKoeUAZnl2n2pF8Zj1Sl1gaQ4EiUFDq8s4Tc
3J5dZQaXyblsXOIv6hnaF2ytSAzF9jIh19jqc9gRhcde9AWWd4gjwI3w02GnkEHQhQC1INDynHhl
LsMc9iNgY143vFymGNeRf9+DjzUOraYqoCEWUPmJKCsojm9nA9mL+zvkQ3Z7crx91LcY6Dw9zN/b
OemRHf1GNtg7Jh9O8rXJVo/MN9IL5BvtfcQPWGDegZrIkPWOfuntqFy7E1MXtAikvXDauWt0pYHG
O6ODk9cauPOxw4DfAIUTLOmjpcdPSuVyyaiUq6UnSpdQnryGWS1V8MaUv1Vjpboqb2rmalmNVMzq
6pJ812hKG6PaNNdKctZsttT7aol2tma5LjcxyqWlJy0VRs6B3KgjbuBLHVlVr/OmWdaba2MclNpo
NqvrZkmNNqtGc7UGqAFESUmroSFUV4zmE4mi81T7JRNsrpzCCRQJSAxfBNqXqvLm+YF3yJzfN6pr
RivTZasLDqRSnY1atTACvbqgRt1sb1Q3O0ZrY8MAFW6CUK80NjYapG4+/0MW0kILoDDwEKrnQiMe
FYrG0wYouA/ZsqkudakvTXXJ5mQQYMfVdrvzQg01W3quLZuYjs4yf7Fp0AiwRnqFggW1Y9FtNlfq
lDfa2JityvSvWrDZemPN6obQIkkkLf3QMTovX3Tazc6m0WwYMh7tajanWi4je3yOaENaV+VPDaqC
tdJR5QkrUz7zrLMh88ilOJ71FS7HBOG+wI9bDtXY/c63pX7RgxrPCp7nnjpZq92G6tfY1AAQmkur
5ibEEQMe0DLEerPzogM/ZhM8r94wLOwFacWCxoT+ER88+uhPZSDCGupgSBsQC1hIL7KODKmv3QHv
uXYAF8Gx7/gBdvfORwPXUUFfvVAVuyG3jYAz0KdShT2kRjasn1tWF7lkWozW/ywfkNDQQ1Nd+DFy
vCPPCJTTxh0jy1BQjmaznq+uV5i3Mup9vUsboob8xam/3Dm562Ffxh1otvzFo3+Pt9ABuvfylt/H
W/VBoaXPqFQrKGL8camGF0k8o6JGGmZ55fFqSaIsNVaatUpdzq+uqfX9rLmxpYIJVzfJD8bQKtdq
csO23nEdL+sqjzslqV2NtlFZr1fKS41S+enCC6VnlbpZWgL1lu9pueVG23wuLTfw53F5XW6xVEc8
jlRarnDSdnmpruY6qKZ8afXO+v9jvUqWG0eOaBBgAVCgAgQXgGSLaqm1NdAS1cRKYMb2eNrhi68e
n0b/4d93boWFouQ5zIUs1JrLy8yXnd9R/TgGuHvWBYlFhsrBfnRQ0TXRzPIi1mMsOb782zd4jx6x
HC0mvfBIREtt4J7YdWIyfEVXu1NWC8cBKr/1bFv1Z3E+wgurmH2Cl5iH4t4ipGGOUijPUnrmBSqY
+rETeKH/Z7lxtwg0RUekAwMasW0Oj5IYTngxY7PwtK20oyK7cxqAEY6QPaYgZqdjHFM5y6OZuOit
G2U36xzamoAymhxA48/S+cohWV1L0GUAFDk+YciaDrWjGfIWqj1yT4e8cGF7wWwUdG90Zfk2JmTJ
tUZV7ZEoqHwfq7ktCmfFeY3/mIPj2GZoW1qQyCgEPHobj/EH756A0qi8mHJy8RDAyu7zDIueW+rz
tdoB+u23zr25vv5yWoUbYHDSJpB4j2MVoNB3G4ZaqFuDNBY76iLjfdEHusYkeCTKWsbsd/cPt+qR
crwKPG3cBlUvKyCdnwHqVmBRfcWHbz6z6go1VexSiWPWTm2322UQk5WXjnvxybM2zidPA9I+nVjm
DK1qwRrD2p41XB/vVp+xUmXMQI7JEutai7UbWEPydb3V6xshS8au46rTQGUaXixGfk0cDnjgYV0Q
q5l3MXtNv4WESE9TrG+65Mq25hxsM6qHGUUCRHQtWRhoOOsW7DuAAVU0KmlUjm1N8TABdjiCx94c
HbhmqMFJien8T6Jekhu2DIJFl6lWb9VRK8K2B5dgej+tEFz3PD3IauBxliMnOfrqtDxxc/FS1exn
GhXQQAFZrssTGmcI6oRkRAZyRNqVHpJoYThNGMi0sRqTGJdq3PAYcH064J6C4qVkzNHAiJID5TaM
BCQpWJAd2DItoEXAy0Pk7gXwLdAhcejXTfGloN/DE2RNmrt7TZ6AkrWQtEogWc9X8Fcke1jLofUr
Et51i+SqTZ5XaYacn/d+h6VMTu8Q8mXCp2X3wbCw4pgh/6rz6iU73mRZ+5I3Jwx0pHIJEdaMVR54
8fcEE37ANgw51DA3C3A8Nuc+a16qshRIQnAZTBOPzZEzQneRYqdAV2H/k2Or1a9CoPCKgm1F0kNz
HvJfv5XP0mwoh4DWoLEyOS1HH/u2Kt2XsLpAKPvKdqJzt83VYFZ9f9pnpBzn8yznAoa4lPZinNcA
DS2AM0OOjikOnNMmmOfAcQ0S5hwWHB9ea4CyCwglGcAT+cuhaPrejF8ItB/a1txhPfzQlZHyQ7Xw
l9OpEpjnPpnS91DPOrFX/jJauvPlAuqyv56rJWUxf7qxbR4ZASoJSejGmmPxDsueWA5GMFL8luKj
ampMocDbD80pxTc6jVFW5YjDFo8eIe+awDKK+naKbYX2VxvFiMqh62oBx0NE4QGxvbbJ3vM5/28h
/H0erlcuD4iSfzoJ97EzuT6NGNUB9Wkz0OIsuciKdsQvJEUpQB8cw2BEPV5TCEoM0Rwjpk52D3uz
w1Aq3AiwmA3mZW4RcAum3cE+9Ct0ciptGkCr7DDAbjjn89bBKUq/4D8+hO0jtLyZfP6xB2WpkP++
iqct6ClXAUcWLSAzlVCa0xqUfngwsyRHqU2GqoojgaiCpHG8KZqX5sMEVUAma3A7Oq7PyYeSTV9h
TwFV/yhRjASgSazIIbI+79Ki3FJCF1vclPBo+eGjRzBrNXqUHS6loMYnmwTTiTFahakkWfLCQ34/
eQIQYNJ+TWDQsnWyGsR8Hiyg2BmiBDMfnsRLHB4yD8E9Fede9m7Fq26KKY3KMqXiWHenRB4kHTiD
rRkVPw4tKAx1WQ9xPrQnbKb7Akw1TSJ/Hj7fJpxm0fH7poGqh3Mb/pg6ocsjFqAUZNUDZJWMrAKR
tebNmH6PyUzUgok7DplwcSTVyGQlbNujBRXGFS7bZMIK5aJ/KzXBxbf4oXma7udJo0Rkh/N+q4Mp
jmUhMchIyF4HRXDj2LazlSoDDlOSVqQpgdReNdSWNJBGjUVzoqrJv//z41///Mdv40xSAvFp6yH7
y8YkCWlvNUo14h93kiLttSAAywQlxy/HdV8h63zbcPV6QkUL2TMHQH3lQ56IbbpHCMAmLxAJndzn
G8iTtJeJWYAX5jsuOQ+AxjzZQ9V2OQqrLh5xpNj0EX6VicN5hJfAUQ3MYS8xlWXmGYAnhg0CYCHb
DJRwTm4DMuJ0pXoM6ly6hdekuQVylSClIkJVJ8/t7dMVhdCOEUd8K8FtMMd7fhJOloF6Daj3jBO8
9ES4ynevsiSXduAx70L0YlVAMrBKkao0z5P95OohRclv79Tu+aB4YQL5uUny/PszL/LsDsOllIt4
YfI8giipaEb/xdbo/iFFlnDLpGet7peTpfrZKdWX67X6mYqCLVhugcBmUg38tXrcKfWXv97c/A0r
WJtAR3etvt/tzHtw98yL4+6s2s3nSHyYYwXsFfnLKCLhyetraA31TN3p5f9/HR//pXsSICgRthcM
Dv1LeqPKH+F1GMUA1592f1eORcEfOfEUyS2aqwLf3XLJMyQQYPX51+tPv/5gW8CGLz9+/KJQyyNn
ZuKLpphjKTdDKqh9OaVimugeoU2eN0Y2qIBM9fCuOBW+mhNXdpnTdt86lZqfUQYswcpTGtekwNLY
zPRZ8BK3WTiQ1qaEQtkMWptSCtodPF0l1ENd0m0aH2dNUyxasUxAc8V7g7RKRlsjQucVSdFyKe1e
zYEnHAd1tA9MSOAZKL3CWIbbLyjrL4k/ZYn+vIAeCmvk7mJtRikWwpVwFwjDKllzdavLxAd7lKRG
ZU6iSut+jAQhWXQPRItLGCI3v5I9gWkd12bTFh4pk/Xu8YRMQlGvm2GKNi1TesRi9chZmIoKlxZX
VqQ/4Y/IsTa0SKCKuhK05+sR8fkJLf89uXTs0OdLWuwZt/yWhx0qTSwGi3G4sL1gxj3OYBnYy2AX
RAcPUP+NFnlpxshLH76gvtIQxWuZpLZC867mQHtyKwwiF2hJQFNuaNH/oMhyuj7UVHmgsnnBV6gT
5YGIRUbEAj6Y38GAZIY34asitaj2F0iN4L8GLPD3KTcIZN0YAO9Cyor/Oj0Y8jFuyeBEWYNkh0Ev
S82QcqDXoIQFQEL/2Wh6QJL5xtsmwewEKzXQzqI4A5YlCUJs0LAg+nSEAGnvcjS9MSPN7868QDom
aDjeQUvs2F6EJAc6KUCyF8gQPOt0s2Rebfwuk5SWXCOBnJkNPsuz+EWDE6HN6xqi2niKEyI5xZUp
7UUedS+WDror6XvefZ48SCJGM8vDt3L7LZQG9gXpfD+0PD2l7KwVAdWlBLFUL8hZI0fYMW3wHEuB
fXAcx6RS5HXYnqsF32PbyzFdO5triyPwm6JrWKR1hXLSQq4m1rS6dIOle0dWXqxhtKRUtp4tVgsN
WbYF8GJ2PEXTSXotasidRd+kiNsfrEC7YYQ6cQxuOEtgpMPXhDS2aWwsDsN7JzAggC+2AQloaWMh
vu3DnON1LHvezdAp7hPkyVDPHHfgQAwRygVfPQ2BQQiRvx3lBHjLiC0i9+K+Iyo5nCXL3kiWGckY
jO9lgzx/yY4mfN/JBpgxBskgEyCfyQV7c925aDWuIJG/hR6LjpNqlFUNAKuPAJi3QIX6Ys/dKyTa
yYXjkNQW5+xJoGZuOB/TqFOQQT0qs0ENNzCTxBVIkGYFmrLLCn3om7RgyRS3md2JIZxkih0a2lpm
Ss7bvLgJbfs1HdmkWyPvehrqW0p3XFK/sTUFgDd1NTTo+e24VEqh+KhOADX6H+PVtqO4EUQVg42J
rTY22EwGMrM7MFojLSwY2wxSEmmU7B/kbff/v2Pr2m4bouyT3dXV96pT55z/JzAIrbvAqIXT3S0S
l0u/SJyUUTh7ABTDJqEf704Sr+Eynlo0TsUGoiyYTRNtdWeBset0RRO5xAMUD0JpLyO/lxZ25R0d
NNeSy0V1S626nARTytVoTpUACsFix3kfWcCVB8LfdKxuQ/rAVieR2dBLkVStVCHtAIom28rplAWD
uYM7lX0+e+2opLgKjLjQYIGS3IxmJvYzG+9IGmdZFMZxF2ACK/z3Asf2phhYasnGvtzihz99ZJvV
GFTS88e5vwBZAqGToKq9RUYnKo68RymOgzzgDRj5QY+6YDrhAh9W/1OH3HSPI30Ow55AEn3Kiryr
j54f34dJkCRNLxuGyTCKEWP26tjdfQ//KDV6WFQdjoOJIaZ6Ffh4aJ3EOYus+gykjKroHhVKtvwo
lJ5gCevrL+jwhhzyAvWYzBimIGGBMPabU07hrDAoDE7qvGazWTLE4XLSk5jMriNzZNkyWUt3Vizh
pxH/BsEvIi3yVmqHfjNSSRfkfNB/BT5Aaz7u9m/dcrprnT8Sw56PCHNV7hGZNB5afQc3wiq5vieS
QKUlJSi64BCxwbK9P1c4IRzD/ueFuIAkBDjg0bY3ks7fHX9DYdbNkDBbP9GR8c2w56x3gAZ1oI62
fBLNihfTMDcs7u5NFp8Cj7jqIx7Lg4W946AcnwV76Rr7wrRmYbpvr/gmif6hGK1KWpLaAJRVaRKM
Lbr9UkdTI8mt429mJQ+Lu2vKaDlUmqB1r/8pH4Bjv5VbAivCVaO2AnCH1dFF1FEtUN2KOmrlOi+d
OqKRLtaSIfSorNQ9r9CTgiHbc8JIaqFFk5SFG9QVXJM4NbC08CHMrTWFs3NVIfaWWRAy1oW5mzvV
6+fN9mWxtO1FEAmwFl2ZaiRkPDHxUeyYLVPLmVkOTMnYhLm5Gx1amdcZcGwqLTEOJ6a7oLuMRJ8Q
2R24geWVqdfEU1h1nKkjMKSLcn6Fu3Moa6dVX+WFbosG4vymd+Uy0KnpvPp2EuTyYg1es/kZmVOd
Wvg4xLA+891sMOUw6K8oLxGFIHFy/FaQQGjmrEQ4w39xwayAzyeUSCfMFfR/RICGYZBizJ7EWWan
aXQJ8jHYaHVqmfNLb85hlg0IbwWRUF/vEN41yRZmrqJWEY+B2aZqywMrb4zW/M5PM8sOz3OhbSkz
fWY0s5xNZhwVgQlnkQ6h7mko4UA1WXoe9PXmHaclZJjEYR4WymO46gvjToKOJlTMYTzLEKTOM8np
9lFhkmj4UWfBJObOMCTqKuLoRqRxe4phpn3rziNLRrJKx+9M4OyGrxcom7oge+mcxdOENQiHwIuT
pXR6gbcKYsIVu0wTZYymSVgMheKG6+/29UV7HnQmkhs08DYRBRRpXtiZRMHlCsDP2+N/d3W1Nbdb
4o5QQS0XkBtJKMyEk6e3OGgsXe/zN0hkyIVb+bFKAFQRgThg/OWugQlH3oLuvJ9E9aGqeQqULXtB
KSc/wJInQSi4hk1i7PDtbvVvI/QElmsHDP1b+U8wY9gcmXZO9/6GIhTpriiAB7k7aqaBFBF56liH
yL5OEjAkzJAS048RwTZLGTfFvKYixYk9F9sRPahmhSPjW4GnBdQutmIXKm6jAe+45fcsP1DTDlUb
G6Bi7EwYu6a7uEA9dAjzyY6d6B8JEfrLA0+AKu4BFkWKaj7tCsWuQ6bCJnSyDaUG/1cIupSfTlCz
F7VWHAtGrV28xPdLL5UXJUGogYa5cUZeDEyxoJo3DybTryBBfC5yI//p/fnx/a/377unD388z3WN
0+FYgejVMCN5VZLI+Prvrz8GAMiGRcsKZW5kc3RyZWFtDWVuZG9iag00IDAgb2JqDTw8IA0vVHlw
ZSAvRm9udCANL1N1YnR5cGUgL1R5cGUxIA0vRmlyc3RDaGFyIDEgDS9MYXN0Q2hhciA0NyANL1dp
ZHRocyBbIDQwMCA2OTMgNDY3IDQ2NyA0MDAgMjY3IDI1MyA1MTQgNTUwIDU1MCA4NDQgMjg0IDQx
MyA1MjMgNTUwIDMwMyA2NjEgDTMxMiAzMzkgNDc3IDQ2OCA1NTAgNDY4IDY3OSA0NTggNTQyIDI1
NyA1NTAgNDY4IDU1MCA2NjAgNzEwIDI2MCANNTA3IDYxMyA3MDcgNDY3IDI2NyA3MDAgOTEyIDc5
NyA3NTkgODYxIDg0MCA1MzMgMjgwIDYxMSBdIA0vRW5jb2RpbmcgMjIgMCBSIA0vQmFzZUZvbnQg
L0VFRkZCRCtHYXJhbW9uZC5Cb2xkMDc1IA0vRm9udERlc2NyaXB0b3IgMTAgMCBSIA0+PiANZW5k
b2JqDTUgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHlwZTEgDS9GaXJzdENoYXIg
MSANL0xhc3RDaGFyIDI0IA0vV2lkdGhzIFsgNzI2IDY2NyA2NjcgMTAwMCAzMzMgNjA3IDY2NyA2
NjcgMzMzIDY2NyAzMzMgNjA3IDQ0MCA2NjcgNjY3IDM5MyANNjY3IDQ0MCA2NjcgMzMzIDY2NyAz
OTMgMzkzIDMzMyBdIA0vRW5jb2RpbmcgMjMgMCBSIA0vQmFzZUZvbnQgL0VFRkZJRCtBcmlhbC5C
bGFjazA4NCANL0ZvbnREZXNjcmlwdG9yIDEyIDAgUiANPj4gDWVuZG9iag02IDAgb2JqDTw8IA0v
VHlwZSAvRm9udCANL1N1YnR5cGUgL1R5cGUxIA0vRmlyc3RDaGFyIDEgDS9MYXN0Q2hhciA2OSAN
L1dpZHRocyBbIDc4NyA1MDcgMjI3IDQxNCAyNTMgNTA3IDMzMyAyMjcgNDUzIDQwMCA3NzMgMjkz
IDQxNCAzNjAgNTA3IDQ5MyA1MDcgDTUwNyAyMTMgNjQwIDQxNCA1MDcgMjEzIDMyMCA2NjcgNTA3
IDQ2NyA2ODAgNzczIDQ2NyA0NjcgNDY3IDQ2NyANNjUzIDQ4MCA1NjAgMzYwIDg4MCA0NjcgNjEz
IDMwNyA0OTMgNjIwIDc3MiA1NzAgNjU4IDcwOSA3NzIgMjE1IA04MzUgOTEyIDQ1NiAyOTEgMjkx
IDIyOCA3NTkgNjg0IDU1NyA2MjAgNDY4IDQ2OCA0NjggNDY4IDY5NiA0NjggDTQ2OCAxNzMgMzMz
IDIxMyBdIA0vRW5jb2RpbmcgMjQgMCBSIA0vQmFzZUZvbnQgL0VFRkZNQytHYXJhbW9uZDA3NSAN
L0ZvbnREZXNjcmlwdG9yIDE0IDAgUiANPj4gDWVuZG9iag03IDAgb2JqDTw8IA0vVHlwZSAvRm9u
dCANL1N1YnR5cGUgL1R5cGUxIA0vRmlyc3RDaGFyIDEgDS9MYXN0Q2hhciAxIA0vV2lkdGhzIFsg
NjgwIF0gDS9FbmNvZGluZyAyNSAwIFIgDS9CYXNlRm9udCAvRUVGRlBHK1dQLlR5cG9ncmFwaGlj
U3ltYm9sc2IwNzUgDS9Gb250RGVzY3JpcHRvciAxNiAwIFIgDT4+IA1lbmRvYmoNOCAwIG9iag08
PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UeXBlMSANL0ZpcnN0Q2hhciAxIA0vTGFzdENoYXIg
MjggDS9XaWR0aHMgWyA1MzMgMzA3IDM2MCAyNjcgMjkzIDQwMCAyMjcgNDI3IDMyMCAyOTMgMjUz
IDIxMyA1MDcgMzIwIDY5MyA4ODYgMjE1IA00MDUgNDA1IDI1MyAzNDIgMjE1IDQwNSA0MTggNTMy
IDIxNSA2ODAgNjI2IF0gDS9FbmNvZGluZyAyNiAwIFIgDS9CYXNlRm9udCAvRUVGR0NLK0dhcmFt
b25kLkl0YWxpYzA3NSANL0ZvbnREZXNjcmlwdG9yIDE4IDAgUiANPj4gDWVuZG9iag05IDAgb2Jq
DTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1R5cGUxIA0vRmlyc3RDaGFyIDEgDS9MYXN0Q2hh
ciAxNyANL1dpZHRocyBbIDUxOSA1NTcgMjY2IDQ2OCAyNTMgNDY4IDYxMSAzNDQgNDY3IDU1NiAy
NzggNTQ0IDQxMSAzMDAgNTExIDQwMCA3MTEgDV0gDS9FbmNvZGluZyAyNyAwIFIgDS9CYXNlRm9u
dCAvRUVGR0ZPK0dhcmFtb25kLkJvbGRpMDc5IA0vRm9udERlc2NyaXB0b3IgMjAgMCBSIA0+PiAN
ZW5kb2JqDTEwIDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgMCANL0Nh
cEhlaWdodCAwIA0vRGVzY2VudCAwIA0vRmxhZ3MgNCANL0ZvbnRCQm94IFsgLTE0NiAtMjU0IDEw
MTQgOTA5IF0gDS9Gb250TmFtZSAvRUVGRkJEK0dhcmFtb25kLkJvbGQwNzUgDS9JdGFsaWNBbmds
ZSAwIA0vU3RlbVYgMCANL0NoYXJTZXQgKC9HNTUvRzg4L0c4MC9HNzIvRzg5L0c1Ni9HMTUvRzgx
L0c3My9HNDAvRzQ4L0c5MC9HODIvRzQ5L0c3NC9HNDEvRzkxL0c4M1wNL0cxNy9HNzUvRzUwL0c5
Mi9HNTEvRzc2L0c0My9HNjgvRzEwL0c2MC9HMTkvRzg1L0c0NC9HOTMvRzMvRzY5L0czNi9HMjAv
XA1HODYvRzUzL0c3OC9HNzAvRzI5L0cyMS9HNTQvRzg3L0c3OS9HMzgvRzcxKQ0vRm9udEZpbGUz
IDExIDAgUiANPj4gDWVuZG9iag0xMSAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVu
Z3RoIDEyNzk4IC9TdWJ0eXBlIC9UeXBlMUMgPj4gDXN0cmVhbQ0KSIlkVGtQE1kazRXodCkiPmCk
wWYWHcUXJpCQxN11GRTb8bnO6oCgvCGGZwKE8EiAQAh0OuHRJCGJeQAhCQQjolFAGKV0VBgfOLqz
Uzs17m7Nn1mrLGu35kfHbXZnw1TN/tk/t+4996vzfXXOuRcwQtcwAABbMzKOHk0/shcrqCmorK4q
Tkqvrihm8bird+mB42sCJ0ICW0LppPCQf4aHBk6GR9MLK7Y4eFsc82gYOsQ41q78iSD+twlnUu8i
A5EbAtUb++O4tzcxkgEIZa5dH7k5OiYuPuGjxL1JbA7v4G/TDh/95OSZT89n5eQWFJWKKqprpA3N
LUpVl0bn8n2OcbkYn4/xWRgvGeMLMG4qxg4ibIyXgnFYGIePCVgYPxnjCDAeB+OwMQEb46dgbB7G
42JcFiZIxrjB4lSMk4Kl8jE2C0tlYWwBxudiHA4mSMGCsABLScWSgzSpGDcF4/ExHgtLFmDJbIzL
wfhBpmBBEGSfqq6qrmsUl+Ttz/tForxViX45/J9uDBAZwljL2MDYyNi8ZhtjB2MnIxHsBawQbshv
GEfg02HnYQbwgGGgA2bgBF5wHUyCceAHfcAIHMAF+oEeXAE2cBVMgS6gBSNgCIyBa+AW0IBeYAAW
YAc+cBPgoAcMABMYBRPgBugGBCDBILACN4MVdJYRymAyDjHuAgb4+5pHIVdD08LSIMDsgn9axwmH
1/s37I5M2MjdNLl5YcuP0fs+eLL1PRKJLMbt2rYdzf0w6VeKhBPbZ3Zk7kzZVZ+4b7dmT/Ne477j
+6VJpQe+Yxcm+1Jk//FGrDgjViqp795nRwmgA4F1YW0zndO3kRsW35gXHXP7rvi1tzWTijExPF5l
vlyMVKpy5WdRzsr6sIiV7tf0ZJSur6enp7dXayZHDHNWv8c7Cft8lgkfYlVfUQ6iSkO15eJwzkiF
Q26Hm60drglkKsg9FuS+ab6jfai5J5nOgWezh88cRgpUhfJcVJHXWFInlolFZTmXlaqS+k9EcHdb
B66MbevoIdvjO8nWIYUPJpjB/tRVyhU1jU+1eKtXx6sUITntQpkULSorbsyJzROaPFXxYrf8+gzi
7neZnajBOmQbd5rJoT63bpWBff/9lqhXfQ/I26jj7dAr6+z4su++f9rvn5245xwf9JP3dIv4ovRh
/uO8hYzZRHgucZjeSCcidFjrdvFeVH667lxldlWWRCRrLBMJxYVNcENheYck9sin/ebS+BJz6ahw
SjRZNid+KH5Q/6DlC7j5Zcf3/0AIJoXTMVH07v5EQxZq+Mxe7K4dE3tbvTof7iaHrU6L3WXxWX2G
++Q38CAV3ve3+wgVw6QSmE/US8qHqPKBwt/kaRppsNcapHppn1QnwataK2ora6S5iuOw4oSKDqFZ
yBFmBnFBHOwWQcsC2+PC4qN6cScxrYN90DJUSzR3dBHKJiUhPIvQe5j7mf8+wDzHlPbLB1Sooc3V
6e+ydk+o51Rwr5JoVyNKor5LjBZAFfnEWVEtoZCfIRLalERHbCNUCVVDWZCqhaiPtWjMg6TWNIS4
+sbIiYE5/ZjBYICN+j6zFcGf6V6FUXuYN5i9hP2albhiIQnXHeQ+00+4DAOE0YCMMp8zvcxBwuYc
Itw+JKf0D8ITok51heKcVDassKtMX0/Nj7kc02OzN+/Oj9jdExMzP7v4r5BomgHV1RMKaQvRGZsB
NULNMqJWWkyck8gJdex2iD4IHV+E3lHhX/91/s7nc199+wMV+vRPt547F2Hn48GFWWROdUvuRxU3
a8ZLnKUjhcZcXR5e3CasE9VKxE3lkkx5ljoLFkBuwuVAnrqezn+JfvuGWjNH7dBR6/A3ouVj8AvM
x0sMRrhEIUKbsmT5YpFEeDiNhmmIz03YRW+iw2AqBKJO6igG/hC/TtrMMbZBq/fKfI+BtOpd8JeQ
CepVadXdiEKj6JKj3U3dkk5hd2nrx00f/px2A7XhfUGUrd9hdKJGp83utIyaRwc82inNhMJTDXsq
TaJiJLdFVF2LiiWlLTlatUZN4D3Ftjpjx0CzscXa7oDbHWq7bTV/8SvlUfO4v8FbCttkerEIudxV
096GNlXLZBI5rGys6bocK6wweSTxEpfC50c8/S7TMGpyOOxum4kc6nH9/H6oxw2aqCWmSTfU6yXn
9V69YcBImuyWcepS4M5Wqu19rEvjJJzamAVooIH63cqhGweupXhTY8ZT3RkjmaYy6wXnSaPQnuvM
NFfqm/q7B1sdKjfuVntU3la4t16r6EDUhEqjQrPPE2d+f564+FkJURtLH4JyILvWoXWgVKjLR9rJ
3r4Ysr9Xb0BIjUFtRAt/FFAlYSsRkFxYyb9ER8MtxSpJK9LY16JXoRbFuPKWmsSd6ptdsLaWkKsQ
FaHqVqFFe7R9dFJ8UXcYnnNJkx8MdqAw8CSKSsbf4B7dqHar7LHkZdlfyl9Llupn6F0rO7dGUG/j
QpfiwpAofZ3ttCsRNl4kL2QjbOjUu+MvsZljt9NGBNqdGkH+CR7Mo5n5NIfOR+hwkmvJRkcE3mPX
Mj1Fk+Uz9Y/KFuXPtK80Xw0/v7M88+TF4g/OnomeKR0uVos7JZo2Vb4iHe6obLlYVH5Welge05zO
UtGM2IOHSGt6fLr5lCvzWtr8mYX8RwVflD+pX4brl9u++R6hCp5Rh6hoCkFXF+rXz6lc7WvNn9V/
VL3qeNG6pFg1MPDR69V/4Tp+lXDr7uKPiWWdE18i3uqoXTj1AUGt1cFUxn85LtfYKK4rjqtqdu6U
NE3UAN2dpbvK4wMQpFgl0FKJChKIozQiIPFSUkyh1MZgjNde7669u7Mz+5idO2fu7Gtmd9a7Xntt
7DgGYnAM1DxEcaEY0sQqSGkNdVokgiqhplK/TKJL1Y7zYe5II83VOf9z7u/8LzOFb0j34myZz4YC
HN2HDiEJpCTXhmWchGjGlSyJA9GxX/3VGRrznWyd6M0E1eOZJA5CC9mG34TXyQa8Cd4iLAlAI32a
o1sQdaFqugImsZbiR+RadkY7mS8XyzmjYtTz5dLF2oOC6jzPaNtgX/sbsC8YgIgYgPZDB6G9l+ve
hdIFqZ6YiN6KnYlVk0akGMjxmb1aA3kBb4SdhA1CLL0eGndyNIg6jFA16RnrfZC0XiKP8f38Z9Vp
fWr49OTF6bNz4w/ZgQpRTa+SL0HZjUM4qoipNucxuiNKWQf+dSt0tqwEuo4+Rd1A125cBZR1H2To
0wuMQeraqexsfsoYrrBVODFuQG2MG0dfP4MsB7Je+3Z9DhHI45InlY1nYxqbTBBN8Lbmj2aPZEQc
IxGNvWcfo4OPln+Cymo9O54fz36ojxerJWf2hDo2zuWQlUBfIdlaqVlbBetf8Xybvrvg4ntyepfX
X3Zcs5zoPraWgPUqmcd/gweE7WeuMAPMFGM1Mlgvguk2i0BK3ky3FlJDLN2GupVIKu7xp3uUmBpT
RBIvpEmyGhs7fsc/FSwHzV35tYSuSDu3y01yayohi3I0zaZ75UAXR59H9GW0mTSFOSmbw5p7jrEQ
M6J8rF0tnNHqmYJeKRTNXDVfzn2sfUIUAypqUcmDprKK3gdDbomucxzGx2S/R/M7SALea+ASYCvh
iaZFJW4jK6J251LF1EBiJHo1fDJktPet1unP1G6lXW6TWftpbeY0Oqduz7XogisbH0icTlQU57Bc
T1dTg5JTC6tCiouDKNs0swcTXc5EG4H+4EgbHHUr7/sg7f5NB6hRr9393xyYX15TR8gpj/W9eoVU
sgOGS7d0x5cwd9EeRiNwx3LYBX2AHqIL6IxyMTnj0RQ9bXqktEqS3lQStJS3U/NlO7RIxhnm1azo
NRUjx2VVI2N6zFxNGyJ1XAWd3Mc3YJKwuL8fqu7+PiCmt46vwhekD5ehQk7gWroisoS34+YEHJN5
D32t3SEmkqLANaMw2o9aUQKJNqg4uhTx9kSWIBbmQRA5AbqUFo9U68Om23pRcdxlrM3Y+gUZwsNk
OOcahJlHHJm2v6TvYE3SUnlXoLi/760aKwjZvOglI+qgZv9cAI2wj5lbeBZukTIuQcE++z9kTFwE
w4bCCajb4Q8MKyPudvAFuW3RQ2JQCqWCiVBcDjjDCPtI1BEGUeJ86Cj0KotxrkaYLnUcIe82cPRF
RL+P/NDRxpUlUy7h29GL/Eme3Yh8UUi2t8CBPeuALtnzJqx3JwTI8d5TMFTh7vR/bjoKhpYrerUZ
7Z/WjzjloUOdgPNXuS4f0dq9T/YyCSZBHFi2J4U7rESAV9kORhEiOOxWNzqiKAi8xNF5+x3q4XTJ
4rpyUhZniEuX8+mszGrhRdFFLNii+0MQ5u0tbHVTbrqCOdIEO9wBxhcG6dA7sM79rZdaWH4blTND
2XFj2jhdGiqzZi0/Nslh6xliRRwzyHLBXJ6z3OgPyGLReZSVjXTV0156T38zG8ExEAm7YF1CZ3Hd
1ngKfwYPbfSO2zBko5BIxmxvxXUIR8WWZEuiLdmVZOUg9rVxx0gX6fVgyuKfvMvRuq3sjwnd7ziE
kiROEp4L4mTqtJJP1+WJNGsDOCJwKRAU3hO3GS3ZpQtGQU4lICrugw1u+kvm8G7Y2nQMoos5fXPr
8nJtfr5wpTI44urrK57LzbGWhaz/ohqYee7f0k2h4hGrBypbKj1aVBOzLLadnsmdQqPjKpnwWn9i
CthYzOAyY7YUAqp8qvHMz881mD6ntZZ+qcXzfI53FX0lvxHQ/aVu02f6in4jpFeM/sLgB7MjfxyZ
+d2jm9bLf7F2m2O16Q9uj832faRl2FzG1KpqQbExpk3gc3DJTuTuDTjnvjAMJOvF+YKiu4ltQ2VO
Pu5IQELktgvvR5p72c4IHw5yUURnURvQFyjZDlt+ykNC4no0IZ/25FLXe6zvHGUjIKZ7IBzheprg
jS2N8M4rr0KDEAPenZkf1Sf0C7rrZGZQL5isYYcwOwgDtT/DV9YyzvofugwTdY4OPPkiGYmH+E5X
7+G4PynspM83r/a/LYUSAd7H7mB2WmvCk76bh/7u8k/3TPIfpgy7HwrCsFPDGUXz0FXW5w3WHseT
NkSvoz1GcyXg6fef6bnOnxecG9FvD0LT/h3weuTtxcmzWKv1Cyue+nSZtOBYYEaZs6Oglr1Kbgg+
chfTOciRHK7Badvj14BkvItVKZHHr8xvuNl4q9HqoImvn32yhh1ebMxP4fdTk3Bp5hpcmf4HXO3j
pqRRwfDw5TZjr96idei9JXYBjapWs+KwYkzVBlWZqBucEbE31Ss3xTqTSaUlEIrJMisJ6RifJIv2
+/iBVbBpVwCCtlP4D+qE3jhHn0V77atFO0Rkbjddieh3redo0JLpWmszZa1lm+5tvbvttouusVY6
niyxGdHVxf2f5DINbuI843hpK+1OmybpFLfWyrMmE9J2aJlmoGEKaQcbPHFDgGAw4GBjbMuXsC1L
lnVY923tvvuuVqcleZFl5EO+bYGFD4w5jHEwlHZIIFx12w/N0KZpO5lmYbYfuna/7Med2Wf/z/P7
/fcj/I+QEvDhIYzSQSt0US6fnbGm7Jddj4WtFTSPoHfn1hMi7QEA+U35P36fIOX5hFwvnHe3FdLm
/BgRj/lhVxJjYZyKCLGhY2SP9CoxTIcjaNgfSE1h8D9gNYUtIZB73MmdET3wXnOM4kTME7HHDCkd
2x6zBOTB0tiGJ6199XJXzh+714b/gqdujSxlF6cXFmdWLt7O3EnfSdxlPwk9hRxOcK8o/3ny36VP
im7uQB/yr0wJZXEzxpd9wL/Lb+bzcH6LUAPee5/vkJaeoIOn8uuZs0Fl+KO4IuRiii4enT4zU3Wp
bqFp2TjUsaRdQy1XnCufCLL+cveL3+WUkMdNlarTCrlCc7a2pPWw8QBqLHa+ux37kK6mNTi0Cy7R
4S8LNATb079Mnozoko3D8szZpD5tzFgyxoxrEj4g7nWvTKyOLCxnnqGZp+zXnARb9D5wPhfgQdKd
cXevRM19q2Jt/82i5R3pLdSG4dcLafs051OEMxBfQdGU4IIrYA3OC/cqAp8RH3suOm6bLmumFFPN
Q2cGS9GBY7GyCoz/bsO2wkJ8X8EvGngRrCfq/PKwPCjvbu5BO1lycBLzslFBt2JCOsPwJjHPTo2h
Vy/23fsHds9+QzODa6fb0s1sTbI8XAbLiQanTrADr8PrCv5Xk+utpSpFwsqbDdiv1j2S34moYTNs
wLkDbSKfnjK7MatQoAy4Qbi02npQcuwAKNj9a1Bg1YFWKSnwNuyD/hh2J3EpnImPJiX+BEywDAiE
e0D6AsZNIJzwtdvAsyjmTTi6rV32sDag9B8P1QUNgY0s5H4xl8P6+5hxZgwOBQciqC9KhYMYHQIj
tzCSc1DcZtGXyBLyGbj/e4x7C/yNzOLHoqIyOWQM+TMIFRqlh+AAlMSJITArjLJ/nbyLYu418UPB
4NYgJyW+bnxShD7el9nzNlakPniqFC8/WlC1VRkyRQxRw1BVSs4quT38udzZwsHquDVmGbBOm8bN
fTbWjvod6x3SDTpJL94q1pEnKFGNWKMEzdK3xG41kHWYgE3asNo6r5u09UtaPi77VyH3RstdzaRV
eHdToFIwNauWbJFqQHsbxusRki9lzUl7v1syZ82YRs2omjR47bjNAbxSGSni8d2UymQFTikvEdfW
A7m0SkwIyufHfHSQjuAAeXH85U9zhr29IEZx3yAfJGez6Ez2/NJ9LOu5YM3gtox5yNDT3teUrOtu
DZ1mDkEFoSK1XlSHCM6wC+HFiBxUn8JakFf9L5/niV7PCbQxDUwFGt5PH63FzKSl0yxA7j3GBls+
b7rdNCY5ceNgeh9VTJbqZDJUJtOeKsHKEqcnK/Gpiicy7tXGactl3bJquXW2dbjlUnVaxtaj3bWB
ilLsA+th9RHc2qRtblXqtE1t1aoq5RnDaStqPX3EXSStKPFHD+Tz3xs9G2gPOkISgur0ExE0ggTA
7J+yYCiBZZDncLigpypkkiQbe5UpXUo7ZByzjlkm3BeocTITmGaz8bH+vgm0fzx6IYtd1s3VzODt
fYUT/Pdn+Ndn3rlQPl4xXjfXegtVLpuXljBuU+b5Z4/wRw85JMNto0bJefeqPeNaNK/qN6L4HU6c
J1Ll3BEzNp+HIpONMU3YGSRmwBN4WXgKxpkQc6iYU4q5RfGNQIgJsqEBCU3DEB1DM+IAERLwgJ4E
Rdsxajt5QqQDxk473kF0ABM0DOiy2hu669YRT8AVsgVstJEugvwPoIFQEwoSbSY1Rox/E+HvIPxf
ER5HTjKNfjXe5Up6hgm/t9897+x1JTxxL8qoodGLuQRKO3CzsJW/PQbKy3cB/jV9Cfh5nRrYpQEg
BOY84kdi51LRyfDt7mw8xaJMF82mMN8axeVxR7AXP0G4TeQ9TwpnBG3z4Z20B7qgjiqGPAoPElVO
jVmhrjxc8jODwmp2wfaEmXXFe2fSn09xW7omg4MMuzEy/2Let5/mPEIiguJG4QgxJtDyz8QCiAuM
WFwA81eyICPNpNYN3YLAEpELaSIbQD11ltQ4rRbUbfXKitpBh0XQ8m0IvcfLF0f4Lnpv96HBcsn5
2nTrpP664prpClwlbgavnhsNpuPp3nSypyeU6JvongiOodGs/w9/53YB7jAnw64hZMY1YInrE9ou
NYW+I7Y/eijmDolXiFvgOuz15vrbodGFOYn12ak6FaSCqnCqPB4vard7bEYT6NDqgaJGBfTr2mop
A2XlGF+L8G94tjsqcHu5rcGgUlc31FbKKxuPqop1qL74N/a3pVt3RgcL8wsGSifr5+pm226ZHqL2
ec/9L7AXJqG2eu7aWNySqI4UMUZSqCT/J8FyTZ4oNydJX4L3IRoWJ4goCEA0Ig4TA+CSwIJVMAev
EVfAAgwSfuGkBYhcn51yezGy3Ow0ePReSY3D5NF2thEST6e1vvfMTPG9HZJzzaySVTPOROvwKZ/b
54GegN3vZFwRY8BOe6O6iDHk+JLDc0cuTq9ceeJjcp9yW0XsuVA8jNEkQ4RxB+P0OWmUsEBanW+h
LLQF2mgbdNFEkEwSGZSrFPuFchOG6IKYFZ8nBoX/HdkAD7ofMXuO2mUWjVnSrKo+dnIn/0O+Incv
/82P9rbXuewey/9ILrPYNo4zjgNFxR0USNsXtdIyWAUOivTBaYskLYwkdVvXd+w6cWpbsiVLFkWJ
IiXeXN7La3ntLqnVLsnV8pLIJUWRoiSSkmnZlhQrshUfNZI0ruseRoG0aNGHPhQNwLp0ga5SDAYD
DDCDmW/+8/t/XxADKuh1SAdZSKsVbqchf3QqGJUmArOhxfA935KfFcUdjPp9fjFxFwtZX9iDvCR5
RXJU8rLkoAR3kqiUmDCSDulJqiNBJhiGjCfh1oEVJsJEp+nuCpll/0X+ulEj86yo/quWzeHbiFXA
koFYe6C12/W91v7QlKk0stWNJTAWm/ZHlOwvZkCUnCJohBIHGqZJMTkWIfv1o/95tXWoU3Aw/ik/
5e+mAvZj6IDO2K3XqVxy6cg4V9D0qPP6puGe+uzw8Dkt0J4/iR2UHj7PV5Q9qoq1sQXnpoWYgMSF
VD4n5PPLxY0yEyly63Ot2BddkQJVLMF/89w3LCPOWWNinBonVPgkpnGiVszitfvU+FBAFbAGgl6n
BdN6tC4L7g2OWSc9JgoE2DCXhlfZ5WQFEVZXGjdXNxrXSs30TvaT+FNqm7juqZsbpvkJXgaSw8yh
fXC4/VMRNB1KaJI2MV6EdcWDnFgFMBGaXrzZlWU62k9a4U6Z47Lh4kSfUqEyqwCmxyeVsDKuT5uR
LDrryVOrRJWbz9crc4XpDGCykVufw2WiGqruRav+4lefdD4tztG38p+vdjclBBcjGCmFkpgfJobp
5y90tL8DZeeK+bLARLOxhWSZz8cz9CJTiuaph8Qt75ptzdLQrozW5eVe4QRIXWZ7z8DDgQGsD8H6
0EuT/ahCrRxRypWDul4LcE6c9b8l/fmb8zvf7zHM2EWYuiwO1G506N02Pw5kkhSZSu91+DE0D8XI
bAl+5oQehTdE2Ikip4NToYiSP10Ej6HWZ8/vdrbfhtpn6HYHo0BY+ZxqWbeiqWGNyEK4PF3iS1wu
yaeFXKqQKGXW4g16GTA3IvUSfMdzx7iLoLcnr8kWZKUhfkB0WqV3xDpi1dkxbO+Pv/7sdy17J4ez
QTqc9HHemNt2avD8sctg8NgPjS9LT7zDL5zsOVW6UJNvqpdNTcc2cH7gu96Am/Gt9A6S3ancam41
N7ZXH5Yfln+TfEq1OojfW66NgXV5bkwBy30aqxmxoXr3BKUnDKwpi2YsZce6a8GZtyZtMyZGT71L
nFP3vwf63zUc/C7cfqG8//YR5M7hB4pHVI0o08V4is4l5wVmik9lC5niTIaJfckm/lmps5qvpCuJ
crwZ+5ABO5JHxKf6h5eis13hD6f+0vFX366tiHh5K2OMAIOZZhw9jyGOTkayFMjW4nPbPdX435ey
09xUlOomaJqgpbSd8gRgB2SFzOTFt+DzkBq6CO2DzkAacvh9N+nzw3JIHIIu0mmFz0EohJI6pYJU
ad2k2wf/DNJRGhXMecuB9TAfmgknwuD/O3pDWNCB6HCNXxN6zX3aMWoFbisWwHGc9ErjIlPrZJ6D
PX4Md/iGNDLrqBe4x64E+qUHjqeX+noO3ezbVX8KNJ84n/wJbu271/pG65v/FDXduvPfS528COUY
lSfyTCEltvzCIpgjeQZuTYRa38bXEXzXdF1RHasMpS9QGkLj17l0bpPNhhqVFgUmA/b3PBcuwu2v
CT9YP42sn/pI8cj7pSz+/O9yZ2Yn2ZiZq+00ms3q1XItV01c45aZInWP2AzUvQ33orNgq2sXtHld
TpNR8QrAy9kh6gJ4SaImTlKv0KOUjnJSQWKcPEmBAxI36cHhYfoKM4iwg5wsrUyNz00KRkFfsBU9
22jXBrFIpegKMx/LcQI3P1tdKFjy9pTr7NkzV04Zge70UdePpb1DdEzVIy7PKoqKwkRFV9fXLA1s
Ddg+8F2twrv0Nruxl4He3O5cwqtYFXGVzQVdVp/RxjTUCDFmUY5NyK19gVOgNSThiTQlRNMhTnwC
0TEiieje3Z8ffPytjyCWzjKlRDmRYqPTgGEiiSScgx6QKyxNxmZgDuKhGNQ6BrUGoFnIS9hJMwXO
S0JEgMQpkCZTM3CGTjE8kiGWyA0q8njmkfBx/uPK9srVYqlrfWVNqKXqfJPdojaJNV/VWbXnLJwR
zBimUSuscxuMZsSA6j1qCiXMtJlzMvaMuWQuOtKumGvaGbWI81af3WG3uVFcA/yTobM/gsP7ItqO
tKQlkTAES3IUYDxTeAi2QFooQPoIN+IP4oR4Oo/kkMRNePYO6pX4CS+JUaAXwkncKyO1GNzeD7W/
Ar0GvcOMJlwiWBvO3YDoniE2CMRayx2CPYQniCEnJMFR8oS0T9IvJ3XOi+QbUjF091sbbbhzv/DO
gqoKVFXb8hpcEd0li6RTv91svfiHI7W+urYGxq/bbtwQ3aGZ2kBqv9rYvLf0oPrH1D9Efq+ESwE+
kMMr7hVHV9W4YBLQ+4ktvpaeZwU6S/FEwh93g5h7Si+DxwJ6D4Z4nB7cJYrMHTXHBpLymCYKUv2x
yzK4D+vXDCLqwdGxS4bj8uOW49QVYpKyR42RCWaY61OMa1Aj8LoCTifsmMYSHiThyviKQRCeFsMn
XQqsEzsUQ+SoehRwMTLC9LReDX+hv9sL7l4onz4Ey9wy0yhikk9MjhrkxnPoYQuwHPmJ903pG2+z
qSM9R9K/LMnqQF1ylKvwIl8qFZCS8Nn/SC732KauO4630uxzpW10lRYpOa6u0bqWCYlWG+toV7oN
NsaoVlGgtNDwCsaELM7DcRwbx+/4de+5L9/re6/fsXEcx04cQ9KExCWkSajKoC1CRQgm7Y+p0lZt
f6zb/jDoMm0n6n/nr3uPzvmdz/fzrbWIWTxirYuP9rctULO56hWi2kh9/Cf4te/uYIO0zppznUyY
HqUHY5bQoH3ITAybvcfegk62hz9OsjbBKbpVq+JQvaon4y8GC8FCtMDiL67+t7/ta/lBaWOOaExk
SxMwGUuGkmQo6Uk6kk7FLg/xRLznJH/IoD3L6LSn93iHzUbz0MVeE7TLI4URsjgy67rmI/zX1sI3
DJkJhp024vu8/8c2mbvEzYlZRhEEiYhLbGkO3gX3wZ/x2F8HGdD6H6iA1jPUg3CNjGXGkj7FnxiU
T8vEJFCZdAE+yKW5FJ/kO+q4Ca2WE3wiLgrNSHvsyVc3mzdmVgodq/lVeY1ZpZeDV5yXndXhwmCh
P90jnSfEAe7Yr+ABsFk4zCDEYlM0SJF8pBbJRZKUTBM8dr4IDOHRDfjgsD7oRAPvnkLdwxZkGriA
ThtCYcSGjSWQBDwrMgqZimeEPJtnM1yWJ1iVlbBMtbbrWgL4InY9MEmOlS8Wh3LWzB8kM3uG6gqc
cZwduWDrtxLafrAN7em0IGcEHmctnIvkgkJQjBCxYp5OGdK0SmMtZEeRPwrxy6L85Da9uQf14cOm
dzJRKZKNlDqSmCznWm88962NNmwphSJZKFSUOnOFrvpKdmLCptj6oT06EhghgyPui3bfiHckYmf6
6UHVWiaGJry1BkRA2/6c9kYbdoLvJvO8IoiJDlHkc1UogzhKjudRJiOjS9NwGSyC1osgR+UjBTIk
eSWH6Ij3CO8LWCfusJ+kr5cb6SvV+UXitv519EPte/BJB844mwNmxsqhRjgVU6MSRRwA9KgXJ1TA
gxiH8fevIO0pSx/q73fg+oaHY3n98zZZkDiFk1mJ5blpPs8JPKGwl6rw0StgY3MPDfApulYTkJKF
Ptkn+oQAZxXOi4SK5ITM4KpXEe5lW8/U6mJNnlSJK0/26cPIYXajQTPUtgFtK6hmP53/x636+OXy
B/VCIZWVkgEaF0rGSvciM0ekkCrLbH4SPtRTYhbVDLUpxE4ZqVIdXTVcxWvFSMlZumjAtxOIQQ/l
ijnJ1wKnQhditmjHsfM/2a89+2LWmXFlPRO29i/2tnZqr/5tR3psKrDo62CtyEPDIApQPjJkR2aH
E7m057Ut6AWc2rICc/jUsd5ni4itGNXNdskHsp6sO6v5W/X2E8M6rQ8Ekc+NtSGcTIRFQ0wej1UM
lCQi0dADbJvQpUJkKKZ7uxN1O90I0wjZDEf0u/RD+kN6GamqiNQU3Ayl7P31NkVNiRlhhs+Lgkxg
MaqvwdYM+By0OjFSwDz4iJoPTZIudVTEoKYDrF8gCnROiTOSAq/yV5Vmvpm/nC8VJpl2Oi4hxcBp
blb78S4rGvHAMHCCJwcBtmAbsHDOuJ8Ug2o4Tyux8Vg1SuDM8QbxWfgoL/mmvvskesfQq+87iQ4a
Dq7rtzz+5cM7bfiVcSI7w0zGx1VCYFhehAzPfsy2niLWwN/BP0ERVMJFX4r0p3rT7+XwLKpsik/z
N9RmvlGuZCqVyTliY1T/C9ANXODWylp9IbuYvSatMR/RK76V4Wu2D8wzRz9sztenC0W1plxW5hKN
eJ35ir7Xv3aYWD80uXs71HaBC+jw63A3cPNe3keWA4VwNpai1IgcZV2slwkSLhBzetFYZBQNWnvQ
2R/tRocMkQyVViCTSnBVbLYdsshLrETwaaaxASOthq4ZnQvVyFAtWHLnfLmLaZtql4fjQ6yZMgdM
ThN2f4uJ7mtnte9Tz+u24fg8xVnjIVLxlIJz0ZK3nce/DsEwNYbhMKS/oHfpu7owol5mdLT9HDpi
cLO6z0CWqXALHIGFlOONoshJIuRVprIA6ZaJWdP9J/ZZEBvttHOyr2AZ75bPsO9Qnd6zQ6bBYVvI
SQRRmIJ+EPiGh9pVoO3Ay7EAFEbzkUxUpTvKmJ4qBpWHGYvCAOUNu0g6GEKRkAXv4AV959v0PsMg
o0tQWIxIgUmwKfKbEEiJSUHlqkIujlOAFxJsghDwxprwL+Au+DegbuvmY/XwJEklQrJPGVUHk+YU
vl6JwbWXIaSSmFwwzqrFRCLOMzwv8aIgiQkxnyxeKjeI69q39RgzYRhCbspK3miu1JfGP7m0kVxj
btPr7qalaal1p3FRPCe+pn0HaveBi/GyY6Q4nPNXmCbdLvo4vwf6kZfykNrvmKO07oxe26Lv1SeQ
KCZZ3LGkPB+vGuUEKySMKh8XGJEQFLYwA9fRIl0jmRaha20NfunEEbxiKr3LnqdMwS5nl6Nr4LQZ
j8ub4LeA0V6lrTpNx7+V8JCSp+a/ESZYN7NJfMoTcZK0cxR5vSNowLBN//6v0Q6DiCSZx1DefL0T
jx89trctnp4+XjhKFI4o752AL3n3DBwhz/708Fv7TITpNz93vGz4wc7Sh3uNe5vH1i03ib6brgd/
hUvScqpJppfG5yca5XplqjaxVFsqLaWWU+viLaa1lW493fVwFxaAJ8va47b4z4RO1iefSJ7L9Sbt
ReeUe2p0NjjPrlALmZnaTK20krpDyIvCvX/B1hbHl6ZV0rRytHyAOfZ/ksv+t2n0gOMbWx1v44dp
U6XUObmbpu2Xu006aXDiRZrYCwLdwcFxlN7RA0ppKel7mvfEcew4TuzHT+I4dhzntUnTNEmbtlDo
ENBCtwH3CpNuAu2k0063SdNp0rTTpLnI98Mc7h+wH9nf5/v9fPjB4JVJ+8TsIPEGPRI7yBnf64Bw
6atA90OLKqWTycTTRWtLLSoJs7pL4soWtvOCZSdg4dpMLZgntNHCic51/iC9pW7kWvJGabuF3nMi
e03wZEjsT3WzduRt9YH0ofCYf+i9O5pkxbgUW56pzeZcy/3Vt7UBVB1OnT+NHYq85n0b956ZeOtc
/7n+gZF+N+ru7wufsr05lJBmTe4/lz9fQ8OdpDueIysLnBcwY48lBkgvRlmcQhDSOGSS0RQjxpNx
MZ6LZ2OquWdf6xgFQ4RZYiHejweQKw5A2IwXEDsyBse4rrOI3wPcroC5eCTs2tn97HA3pKBJ0NKo
7FBC5amKd55ZI5ajDbjELcmtfNPUrdIihGLKDLQqpqGEtu5r7z3C9N3j/zn2N3zwweuNg3CA6yNO
TqETYL+BYca4eeqgq5MJ479/vdUtSbKYSdalWna+jIoa3P4nph/g9C7mPq6wckTGScknO6UwjGa4
PHrXcjO5XlhZXK3XF4tNWUtnJAX9GOnUGm2uFO0AHoIGUwNY/Va5lSlKUjG/WJ8v1NINYYVvhhac
6MJMdnocs9OTLgfudkyTV0zAGFPtVZ/ml0iB4a3hKBkKe9DAaGR0FJu2nAHGd4zXMOhP+ZWAGs4y
ajzLVrhWvBkvsVIMlSIJmsRojmbD+B7EOIycHwIjtgASGwfHbZzMyyZimSWgdnrEGPhCX+le4Aum
m3xtKGrY2j5SGcqEKpMVV8WfC1fIVniOrsTm4Tq3oi020MW6ZvLzXKxI5nEy78qN5v3SoHq4eDg/
aErRmDqVn6nMVrw1ooH6r9LtJraV3si18fzyXKNenyu2CtcK67nfp28JH/H32c3IJn2DaPtFf2pY
OoWmTyTtNBbl2RiLuzkfb7YiTwoBGJUjGlWeuD+2YV+wV0eyg8I5foSYmEbdbnLajs1mnEUXXpm5
6rtP/sP9oee6992JjSu1S2htKHO+H9s3deREH953cs+M0WUjRpLSq73T0C4NqxR0KkMlBkZFToon
2RazjVKfRTdLz9f9xafP2t1Pl7eXlpaXl9furT1BNxEv8PiGwbQXO97xNwqr8kluCbyf6EnyC+CW
gIo+SJBYkAtEfeb5/SAssHwYBAT0DOJDBr76DbJX6E948KRL8qj+HJWPl4QinxXSZn1rarkkwlRK
SucDWUIJJUNW5+jY9EUv6hm6QA3YTpyt3BjuHbnhfWTm8bRF/2jSchQhEfNCpVIJIbfQOfOTZ+91
S4IIxQSqt5FKvOt3lp9auD6TJ0y/sPw2+aZ0CVfHis5qYD7QYNrCMl+HZamcqqoLxXq+kJVkE+fK
6TKqlywLoFrC8mCeX8TrfF7Erln4Kqn4JJfY049wPBS5XlNB0xLM5LAiLCQ0QbfFrav8TeFeQjho
5X/WZfzAYlL6fstpyzDwsJgvERIZXKSS8aTwCbTKfBd0QpIzB7gDXPa4kyO4o/5fuw5MTEMrr++N
MGQ4EOo5fvrM6Hk/6rvwDn3WduotdX6w92JlvOFZJWr0evQuqvKP9e9jJnKBrTa2Dda4Mi5xmXgW
j0DKtJHhlEOiJDQu8KIEgSiZdFjofKofEc8ed1cQfRB5l9e7ha4qIhJCOIrRfCjmx0kuYKbvctQd
pVk0ysZiLBaSiVwAF2nZpV1O+RRHwb5pfGN139xJbUSZkYJ39F1b+o//oB+qbGTXYOOSeDlhhyiJ
BGCXwqkqpiVUUcZXkl2fIXeQBt8CLQH9BOElGag2IQQoBosAmqfwI953gg6CDkeZOBejrdOvXDC+
+bphM75tVK3EKDXLkKSTdtN+dB8yc9Pxx8lHBqY/to59OvL3wS/YTEyKJfq0ySyloBKQeRUXVKhA
pbMcOy95nz3sLiI5hBerYN12fQ0IK718bQ3ctt1qACHTy8sZkLdBLyDCGMWH42GcYgkuyI0xLibE
xjiOjUdkt+LLEF8abuvyr5pv1C5qY7JbpD/Qd93+39KX5/5l9a17rrpXwzCUDIizKafkkdG/WO7w
bVAUmvxN8EBA+eYK2LBtLABB7t3ch0Q4P+fgZuKzrJtde6V2RvFlnVb9uwZ5bf+1z5t/Lm6IxZ7y
7UzTXLnmI21rGUtHlVAGjwlOeTA3mXAnqY5AKWZ3ieazxSa4a9tuASHdW+PXwKZQ4YtAE9BBk/kJ
zo0f8wz5g+FYLBZlaeNF49/WmVMXfnLM+EXEE/WzFPpLxDi080PfVVaJZiNaDx00dhtJ30XfaHCq
JzBJTIXG0UvIMcT4uf65cWDnW1SZ1iipJ6AG0m7RC814p4Q80HgFFbIg+9wRIvVPu9tSQ5nXCqIm
KWlVWqhcb+tH9VetkvmvRlYPf9zjqE0uzlb9pR5GPnv7ypK30MMm/PJ4Do3TokT2xvOcqmAFqCVS
eBKKMJFQORkkINpANOQessW9D55AVN+FCH5AMliID5gM6aKCDMWgUQsjsDCG6y8Ze/WX9Ze7FEXM
pDDREkpNpUzn40pcqYTVChaVmwN1eJNbAQ2Y4bIgD+e5XOclJeT6LOLh/l9x2fw0Dcdh/ERXL16U
pLRJpxdj4KQQYjQo4YIxXBQD+JIA8jYmIHPAWGnXdmvX/frrRmm7941tgAgEQnhJjCIejPgWDDEm
eiH8DXoqUA52f8KT7/fz5PlM2nOKF5iwX+5ihzhKDIs+amC0sfFha1+Peddqxf7c2Gmf9eeo0tRr
GrVRohm81xFgIFvfAnvEKThODCFPn8EhgolW5EHWliibw6JW0ItG0kYjZchxKS4agkZlPEVef7HY
uUPZBkgVbjc9eeT3ogwl0DzOqpwmkhqXEvNSyt7NGkgHMRaGpACkJnGOhr4RF+xva4Ntgx5IEQWY
TeJrjvO1kyd7lfPq7HRa0WUDxpU9eQduKOgHxHQiM6IajkWAW54AAirxgiwSTIQFgowCIRQJEnxE
CkdElYrR08Hdq9hWzVbddsNn6xymavM/3poXPplXlo/UIho1FEPHZ+SklCXpBKfxsWB0Qh1Un+sY
yFdoQJvG1WhSyZKFdNT+z0P7dnPyJvyorMsLMKegUT+0dSQMw3KIZIMBkQZjIZ8wGaaDXEiU2NHx
B676JusxZt06q7Ec1py3Y7jL7ariGIajBJTzDEuDRIRSVLfTo42lfSU0kBFyOXw9s7a8QuaWCkaS
WFmbGtp00rMZIU4k9ZmU5vxmOjaOcu+te8e1WLN5s91E+w/8r5hsUBXUMsNoiIvprBMUQUkqlWvk
2vG7k5eV7q6o0uGsk+8LI0y31zUw2jnah7UgRiyt5sj0Wulg6V981VjU59EiAvSkXSuxQIzl8Ylp
RuPJpB39+CdSRqYcuFz/dRbS1kx5r1tV1RZx2brk92Lu3lWwBX6pf9NV27EFNZHIaCvbO79thOJq
HN1Hgg0VshdQLM4AKkKR0oTsk7woC3lZIM/uINYh6I9WfHWkcom8nrKJozGz2uze3X/zfeNLlZ3k
1Lp4ulL5H2TpoqAKZW5kc3RyZWFtDWVuZG9iag0xMiAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNj
cmlwdG9yIA0vQXNjZW50IDAgDS9DYXBIZWlnaHQgMCANL0Rlc2NlbnQgMCANL0ZsYWdzIDQgDS9G
b250QkJveCBbIC0xOTAgLTIyNyAxMDEzIDkxNyBdIA0vRm9udE5hbWUgL0VFRkZJRCtBcmlhbC5C
bGFjazA4NCANL0l0YWxpY0FuZ2xlIDAgDS9TdGVtViAwIA0vQ2hhclNldCAoL0c4OC9HODAvRzcy
L0c4MS9HMTUvRzczL0c4Mi9HNzQvRzgzL0cxNy9HNzUvRzkyL0c3Ni9HNjgvRzg1L0cxMS9HNjkv
RzMvXA1HODYvRzEyL0c1NC9HODcvRzc5L0c3MSkNL0ZvbnRGaWxlMyAxMyAwIFIgDT4+IA1lbmRv
YmoNMTMgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAyNzE4IC9TdWJ0eXBl
IC9UeXBlMUMgPj4gDXN0cmVhbQ0KSImUlHtUE+kZxjNcJp9iQbuGIwOdsCirKLgmgQDiFkVxolYs
igSRGC4GiUIAuRvUFddqYqKLgmC4hYvhrmAACYLcxKoI6kp3F1tdr+3qOWv3bNVv9Bu3nbAet6f/
9cw/3+U9v/O8z/fMi3HsbDgYhjmHhq5evWbVohW7lXHJi0OS4xJ2LQnwtd6spEU2tK8t/ZEdKpph
C51m2NF+M5wZglG4AcKNu9meNHIkBQf+ffToh8UMLiydCc86we9mnXBz2PhbjiuG2XGn/2bmR84u
bnwPzwWLFgt8xYHLgkNCJYnp+6mAACpgCeUvpAIElMCP8hdRAULK35cKEFECf8rfjwpkt2JKzJb5
UQIBJQ6k2BIxJRBSfmwVWxJI+QvWp6pSM/PSFHIf+VQX8qku5BsVO7KS43b/19H/9MjBpttyHDAn
ziyOmLMKo+w32G22jWGPS7FTmAE7in2JlWFFWAlWiWkwHXYMK8ROYhXYEUyL6bHjWDF2GivHDmMn
OC6skxw7Ds7ZymnjPOD8iF20qbJdaGu2W2NXY59m32//N/t/4nvx69xw7iRwAU+nBU47NO32uyZH
d0cDne9mf5MHD+MiJF2LJAnIHyiRuxp5IQGBrt5DN6Af+ppEh3FEwHXeMDACeoEIuCANCmAAAZc1
QN9h6E2OQJ/voS90hkHgKNfRAG9boegI/hRJR5HEzEJbkHv5e+hSdAP5s1B4BIcs9DkMHGShQ3BB
/XtoKvQNZ6Hh0OdT6IveQ92hIy3k0UL0E46cMzyjV5Bbl/utQQ6bRDB8zkR7b7upvb7dYDnWD5CU
FuIf6hn2s+7frJ+g83h0gqk4tCyyTunS+cerqkndiNZiaG4EzQ2Gsx1E296zqiYyzRTcgGY2IFkX
mnvZ71sg/kr+PQTERM3tC+PkhbHx/ifnH7dBxyq4WAc3aqFn0ovQH1ddQbYVyItJSJ9TMJ7Tm9Kc
3BhviNDHaZT7s7NBVub+tGQi48ucojyyKMuivquGMjn0lD+KfSS/FmFeB86vrVr5GbEo3S8yiJQG
hYR5J4AEH+SQi+a6omMopPuHhXyvZxHQcT9caLWCLnoj5THCXsNN41B9l4vpvLntUtP5ykvlYyXj
JbdPfKODjtoXB7/e+5f862m9sWeTTfKqCGDcVBQZTTAqrvT49sJUsjClNKk6FjDuuLq2oOqQ4XDp
n6oPNUml0iRpDlCFBu3zdkVO3qYr6/jrRnbdeUTcrRm3DJA9lx60w5km6NXwQ/WFkgslPeW9RtBV
0JxXQeZW7CyK0W/QyA8k52Tl5aryY1mp8DaS8qSZEXmb8oN3R2WyXuRkHEhPJZKK06qzSGN2w+dm
fafGfOpcXZvxTIOhBRhaT3YNEre4jtDRzf6C9fky8M62blN/VX/FcPFVHXTWvtr6cDF44NOB3NAK
AjnkeSQISYUgUrI6DsRKgrP9XUPXltaH8WOrojsirwLEZ2azJC796c8+vI/Lg1tlZEt0R2a/vkdj
rmnuAa0WwyS0JZ7l39llIZMtimqZPlIjz1DKwM6tuSu9CdZuN7u/WrW4vV3D8CCfKw2LjpfngNTw
tftWuqK5yHYA2v6eHwxtFNAVigkY2gVdv3tO3n/2+iJ01o1qhw/05/XndKeZEwGdQQu5jFXJ8z13
ki6SOy3y2s16mUaRlSIDyTJ1sAfxSVlIs4xsjjFnWvT9ms6a1h7QYimffDUlxH4GvY73rhsvDCuX
16W2xfVmjejbNWeLWqqrS4w1tS20aOucMARClvpFg2gxcspCYlfER1ileRk/yCy5Jn0Moh6m/gQd
CLh0ELq9fEm+/Bf07IfrdXCRFjpkPpI9jhmTWHxBt7AG4YgkZFxGCKW8g+PZfcqmnY2xbKbXa6Ky
FNuyUtTxX0QAmsDZEXLv7QgPSpEFSd8ZGeEbI5oPLXB+N24+binqJ4svVnScaTU1tp3pqe6tuHnq
H7oJ7esC6K6OQoVzthTGH0vRJ2rSDu0pyN+/b88X2eDIXk36dmu7b16wXJr3sx6P4Ur2rVWFkalh
iqiYHTGKDakhe4A6JPAgG1IlWtA8toy/bDT+MbQp0VXUEbQgukhpyKjc75LbcK6gy3Wos6yxnm9q
PD04SUAhNyEmXrk9L0wpyV+hR+4ahF8XwVkg7GEynA4XEDDADGfdfULeffiyG87W3dfe3Du4eyCt
L94SDqAHl8GZkzxxWVhTAtkc35HTp+/VdFS1doGWjvLRB8T9PaNJ3WRSd1x1lH6LJiE7JQGo4vIl
Uyn6EOhafGh4sGPwzFDt9dIJHbTRPkq6RoFRqnEucifefcZOq6fc8c97MhrIDJOyLFa3TavIUSUC
1Xa1xItgDIzQGmd2vH0yxRMhIyOCRpwh7GjRzyOM6O0I/uulNbMidomzIX4OHaf8REvwy6PDlsum
4fpbp+/qHmhvqftUfSkdsqbwG+N/vjhQN1h34/SkDgLt35NGKTAW2vwxmke882NE9Ftub8G5nDoy
7ZyyMl4XrVXkpiQB1Q71xmCCGZgS3n2k+VAlefBMvjG7IsuQXpyik2m35yYngZQd6g1BBGNhhG9H
rGb8ImU5fvnmcN9I00jjrbJ7Omj/f3thhU3QjTwoHmL/PpvXJMRewvmDMEwHlVro+wfIQU7giWcn
mok8CRQUyQ4NzjzSHXHQoi0owhUFo991PvHgo9mv1sB5cBX7ULToGG9+5fK2GLItuidzSD+i6a5p
6wHnLJXfvCae5d7Z0Usm9myrjdCHa2IyEmNAYnRuiNcvD8yIeG72t+jZyJ07cLm3s6v6Sv3Y6a90
0EMLbSK+RTZgEtm2swp8if8EWwKk/ftIYvsbNi4eLDUhXvsWG05TlJ1XH1edXqdhsQj8ivwyB/gv
+kQVKZ5CrF0erVy3dL+NuImzoaq4CKu3mtj3ARrtfNRpuh5ruWOjXI1ZiWBzal0IaVt6PiQaiwcO
9wT3DvrFFfgV+0QGstayv7Oosqa+m8WMyYrOeNRn+xX7txhanWOWboxVimB0bGAIYUt1+wv7Phr7
/Pwy+sUHDvhZvPe5Ffgyu5lUn2WjdhmkdKyAtI25ibCYo6MIn5qUoqcaqIWhfZ4egpRZmiyd+yCi
K6JUoFShXq5mvwhmvXjFzhrRoMizvx60vsOy0aTTpOuZ9wuM9xSK6IDId8d2vmyyYrNgrVWmRfwz
chiCqHyidppvnWiWYo1iiW2CeHwIeXiAeHUacJd2pH4eo3zEf+OC9xp68HbLb8xwvWOvWQiuV5tU
UBpLeU9mUh5nUU9bPGoIaTwge/sdG/tU+x2kwjkfOMJY2XTzCIsHDvcE+PYcBbcV/Br3b/u5+2/8
KAdZj2uTfR6acaJ/rI2qibeUwp+p+50YdiUrgjEbJT+XpVofW6VosnLCCHTAf+T3Dhr4Evsm97n3
JvdPB/gz918FDhwE2xb8F/c/BlNDU1lRbghsUkV+ORv7AjSrz0sfTc5r8/ciGvlA+DL85wdHmFqh
cB6kbqt9to24ibGdqrEIqbCZ0O8a+Jz4Mv7FBw74WfrFBPg3Bvd3/V/3ZflfBfgYBvw1HPuEXPsY
WjJXXhlJRfsAa/smG1Evk5r7Dx9r96gFdcbOgtQbvLOXpKkfqqOjt6DL/E/6xxgOHAVVFPmqFQSE
VrsKZW5kc3RyZWFtDWVuZG9iag0xNCAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0v
QXNjZW50IDAgDS9DYXBIZWlnaHQgMCANL0Rlc2NlbnQgMCANL0ZsYWdzIDQgDS9Gb250QkJveCBb
IC0xMzMgLTI1NiAxMDE0IDkwNyBdIA0vRm9udE5hbWUgL0VFRkZNQytHYXJhbW9uZDA3NSANL0l0
YWxpY0FuZ2xlIDAgDS9TdGVtViAwIA0vQ2hhclNldCAoL0cyNi9HODgvRzUxL0c3Ni9HMzkvRzI3
L0c4OS9HMTUvRzc3L0c0MC9HMy9HMjgvRzkwL0c1My9HMTYvRzc4L0c0MS9HMjkvXA1HOTEvRzU0
L0cxNy9HNzkvRzQyL0czMC9HOTIvRzU1L0cxOC9HODAvRzQzL0c2OC9HNTYvRzgxL0cxOS9HNDQv
RzY5L0c1Ny9cDUcyMC9HODIvRzQ1L0c3MC9HNTgvRzIxL0c4My9HNzEvRzU5L0cyMi9HODQvRzQ3
L0cxMC9HNzIvRzM1L0c2MC9HMjMvRzg1L1wNRzQ4L0cxMS9HNzMvRzM2L0cyNC9HODYvRzQ5L0cx
Mi9HNzQvRzM3L0cyNS9HODcvRzUwL0c3NS9HMzgpDS9Gb250RmlsZTMgMTUgMCBSIA0+PiANZW5k
b2JqDTE1IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTg0MDUgL1N1YnR5
cGUgL1R5cGUxQyA+PiANc3RyZWFtDQpIiUyTe1RT2RXGc4Aktw5VRxsLF7yg1epoFfIiCb4RPY4j
OLhQeQwGAogChkcM8lYgBG7CTUIwQiDkhUAIDxWQh4oCDgKKQy0uV+tjWnVVOk6r1ldgLjNtmLWm
q/+dc9bev/19e58NKG4uFADA0l27du8O2bkexmXGnUgTJ/jzuPPPQTOxLjNxrjMMN3Kju+u/3d1m
RO7LyMY5szey3Ju+g4qZKXuKi/6jVP7v4E6f2bZ4Zv+imYefVnrve7GEsgcAN/qCXy9euszT22fF
qjXrNvizAwSbtwXt2vNFaFj44aiY2Pijx1PTMqXZeYVFsjIFoak6pzeYrI221o5L3b1XBgZv3hqf
mHz59kfICoB8PuQyIS8AsgWQxYN8AWRyIY8HOf6QDVl8KPCHXDZkBkAeH3KYkCWAAibkciCTB3kC
yGFBtj8UsCCXC5l8yPeHHDYMcCKdYCZkOgM4MEAAuTzI8od8FuQ42U4gH7KYkM+GPCfKWZYF+RzI
4UGmP+Q5gVwY4A9ZbMjnQg4fMp3q2JAdAFkcyA+AHKdAFuRxINvJ5EI+D3KdWVzI5oekidNO5qQn
CjcIf+m68EBikjQ1LvOX+/9PgwLorpQFLosW/W6BnxuXHuxBAZWgF1wHXwMV0IE6YAHNoBVcBN3g
KhgCo6AMVAAtqAFG0A8GwS1wByiBBlSDetAAbKAd9IABcBOMAxycBbXADBqBHVwAXeAKOA9aQAfo
BH3gBhgBt4ECqME5YABW0ATawCVwGVwDw2AMlAMCVAE9MFF2Oz8RxY1Cp2yl3AJBzqD3LhtddrkC
18tu56lJtIN0O1Lzq+wFlZ+kf/LMPXfh5kU3Pw1YsnLpAUbwsuHfzqEe6Auvd97fY6O+GSsyVnat
Wrv6s99nrrm2dnI9ZwNtY5Kfxl/FXM5azvqBs5x7m7eEN8PvDwwJfLv52la3reZttu23d1wKOrtT
Gmzd1Qy37Lmzd/FPrIVz6xfOTTr8ZkcZhxw91MKHsiEb2l1lqzdjBqNF10TY8IYiYzZizKo6KUbT
SkJz/LAI8jJVRFtIfjvz2psazKjMqsrR5ZUW5eSIM2JjUxJOJof5xW1JC03flxWUF4jk8kvWky7o
Fu2OmmCsZmfDttbN7YG9gcO8RlHb0Y5kbenZQkOePt8jK+pAR2TPkWHP7f8I+3vc87hnaU/zniJZ
jqVnpkfQF+f+aX2DWV53vhl+e2Fi8MG9x71X+i5esyFKulOHcC6RYTXW1dfU9HVe6LVdGf+u6751
wD5pfVD3BKl7XPV8Gn1XMp3zEMv5i/hx/POEv8bdF47JdHFXtj023fAYThqI7Ts8xbvJ7Pfr22Bn
1fARC8moXheCBhb5n1yLSdckrP5yZZwgVLAp8HhSfGpUhtxQUl9onK89V/CEdDAIm05VpT6n8vxb
20i7rR2xtevtTahBZsjVY3n6dN1RbWKlpPK0RlZRpC2oRkr1ZTV61K61VOuxJout2k4M4v1Zl44i
nQnGr8JQUYFQHIOJo4VHw8SIOOxwgdBr3uX1ZzOfM/S0R7jDi6C+ol2nXcUv4NZyZDs9Hj+mzCQk
uEQpIVLwbKWMQGJpp/F8ZS4hwMPUKZV4s4eOqFWZsZ8VO8D3DKvObDZhJqNVd55oxC1FhlzEmF0l
zUTFJZLsXCw7WypL98qQak3ZPtmGooZm1Jk5e8ubWsH4lvZjlPdsPFVAm430ptVTF7b84DkLGFC+
vygCy/XL2JqyPzU0MUIoSk0+Lk06jRQcSyxN9PoixNQT5hN2OWJK+AY58krqQBze6Hv96/P/wppf
tj/oHe4d7Onsabjc0F89UDGlmEy7e/CbA4MBnSQNadqkJymkl1MBKWhnOJilH86MYDnT6ROiSwkX
Y4zhhBAX5YvEotT0mLwQRLK6kPQj41FSZCJXdQmwrsBR0cOKIcVVQ2dHd0fzbcNLxDBd9cHhjiru
OrXPnlw2F08jlCo1qlFrVCpM4+xTo7Zb21rVoEe0erVzUOP0yoo2YgwzE68cO9EKR6HC4UM1VNz+
iJJ/IN344XmEHJcTMi0i15RXalGNqlKtwXSVlrp2i5awGLs7Joav9thbW+wGo0aD6HXKCq2PQVFd
ppYjzh+Rcwwt+WkxlUWXKqVZUjy/GM1U51XKMHVpdalJ/sd8j+KWOrnKSytTyUtRRfF8v6nL1pKe
SnKLF3lCvk61tZwqO02o8n1q7HUtJtv4xLOnDtpHh6/Dd9rh2vsE6Xtk+fMUekfydVQ/Ft0b0hBM
xOKiIlF2wqlkSWZa3qlTCRnhSEphcW65V5lMjsuIcqcb+bybsqpzaEvdQMufMPu9/uHx7rHOe+ZH
FR8Uz5Lv7UWmPm/fzEZ3SIKid2DR20lAupFB5LrwyIQkySmJJCY6ePs7+Xf4E6IeNytNaqTbMm/b
4Vteh9dqa/WehhprZ9M3SA1NjauUagJRlShLFSheXC7Fk8ojPPHk8hh56PyGtTgCf0hhiGs73/bf
H+zzHOwas05V3FUM5nWdQMYibeFhaFRuZNJXWFLkvoPM/U2Exyg+UjCUOZzWm9B2CGk9WPdlKEr+
5oivHwvz9yOROHKl14pNtfYIn/TaAnMTWq2t1lVjOp1eW0uY8fNFzVmTh0Yzr1U8VEy2j0wio5O2
p+/Rp1n3RDcx0XBE014iBo+WRAizOz0aGxosJtPEjf5B+xDScEHXakf787tS27HU1gRDlHPzdh4M
JSnzFtpmOd5uHxlDtCzlmXKU9KXLycUa0pdKUujkZ/QMZdIR1EibpE3gNwiq6r8klntQU/kVx1vl
8Vt3XLVdarihF3bR3XWKdS3d1bK7raAuLeMLBBVQBIwJjxAIhJAHhLyTe5Mb8uBCQsibRyDEQBRB
5FGxPldlu6jo6upoO2PtON3dacff7v66nUb988yZ85tzzu873/NpNEgVmMwg0Qtxlk5I6o2HKQYr
QUGIDQ0dYIMBvYk2YVq9Vq9m7iDiW5sNVE3qHcP5E0HDYP+Eoa+zy+Duxxq0QlJqVJMKg9KUR7GN
CkpFCMlq3XorY38C21IqV9ri7aSdthi7ezGPPzw1cxMegj7G9PXxc6GTI9HQxMhUaDI8ERqPtb/+
x4kkmJEIVybCa4n7d36Uvh6lIIB+++mvmmuHLT6zk4JRHcNHBo3RjlfTVqXEyZJyVfv1RykuUW3g
mIBIThl1qdlkJaEhgY4gSYJJyFToNSlqGHYEuwcsg9ZR0xkqRPgJu/6qYFIyKInyQw0BXl+Nr9yz
DziPWsvKsIPqktYKvK1MzBHyhLxabjm3ora0aZ8ESPezVC1MtM7OslTRXGcyr0fYo3ACrUXf7cRo
W7fdjjvsLquH6iS69Z3a24UMV4tXGpCZ9bTeToxq3LoOykH0mUP2cNewbyAYDPaNuieBd4KeOY/9
s/7e/s/wgiu5oSyqmqjVcGU8mbC1XSbTMDRaNaGnZCYGTdA2E2XtxkzDHeEIFjaFzEO4aSre5KP6
ApgJbrA8pvvMnTYzTQHCYjXQzA4SvmGc10SJfir5EnHWGrG7+u3dL9ImG0kzTTLFYc22eI1Wrpbg
L5caeiEhi8wk75ADhU6jVjD5ymPiIp5Mxa7bVVwvrOawDh3YztolKGwuFO5oydQ26I/o9xAcxpa+
rLNZ+HTMB7+gokSkOxQI+fvHPH8B7nl64T72vOXesTm8cra0P5+SEG2GVgpoElSE0qy0O21eW8DW
Z3WaLJSZCGrnVUNtjFC7X+6UD/MHuH6OXeRgeQqMGnO97aDuPYZsT2ulTChicY8frRQI6iQcGWgp
LlLlM9M2RR9uS81+wIIr4YfYI8eDwfv4wN3ozbmFyPjU2Utzl2bOn5oL3ox80b/oeCkhuCIl7puk
e6bnFEwxAvLyInGHOa0PET3UUyPDn9ChobR6TKERSepwTRs3Jx+t5edWf1CZjlaj7xh1W0UFirrm
jQxlnU4kx9pNUrMIV6il2iamQm6mFammqH3We8Pms5/x/NW94LnaOw8T4XXGyOPQ/eBSt9/mMncB
h9/qdWGyBEUCSjLFE7o2UsAUEBKDjAJoY8LhhDwTmxBolcpkRbu2gawAMl27VoVr9BpCR2kIRYfc
AnoM9k7MOEzOx0/F7ocbp8wmm4V+Od93a76PT8obKRto9Nb210eaJ4FgQj45jX0Zvnn9Bn7j2v3w
MyNcRj6qv1oIrhUM536ClSmOtXBwEbu+5jivUVjetJv3pGSe65KN8oY5/eWg/0hX8QEsvSpz26f4
9uyNtSiRiV7bFLyyM3Xn5ao7T7CznVOu07hnfOBEdGTYOz9wNxzrA2Y+SpodHBt2h0FkxnlhAZtR
TAijuChSP1DtrO5l2yqNu8iDgmMVoLJMWLQHY5lr6Cac5juFXpFTMsq/WNWp9qpGFLTOofWoYw+i
5WlJpfzq5hYpr05QK2UDKUtRnIdt7z0wxMLP/Wmh5iF1l7jmPzsNZicDV5awL5uuHprGiye3nkGJ
p195R1FKnD1p5kCk2FsCgjk9WzdhaZKM2iy89kPWjiN7y3aXlBaziit3V2VzQW3O7tZipipBbdVZ
aKzTaDWZ8Q5TJ2U3gb6TjqELqfdOXBo/Ob249Oe/hf8FIs+cMA6uwr6W32+8hjdfrZ4sH6oYqOg5
ZjxIHm1kl4KSnfz30JvYOn/WZAEerjgjPG/0kQ6DzQhsCVbSQnToQaeiQ6PF2lVtaolWRCaL9UKi
icoiciJ5iyBvsfYJjMPgstGnt5fwW7f/Hv23cZI8pQ7Lw7Jx/hznJS2K4S++P57k7nK5XbjHGaD7
Y3jdp/BKgU9EtwgxnlzAF+FSqUBVY+SRzbaWXiDuVQbCMfb5cUWcr8vjdeN+V4AeNA6QAYVHCtxi
WtiE1SsEQikuFjVp6pi1fJtXnCr2KL1e7BXtiWNo/wLiXTGIb+lsbsIalC8QTywSKBuoRkLQKfaA
V4znp/29Htzd66MD1IvfzPnf50n/ObU4NhYC0ZhIxjC7trutC6fb28wy5sdEfIvI3CtJlTiUsTs6
0O3zevGhwAl7mJolTrUON4AhrrM8HytqP1J/HG9gV3IKq+uEB5o/bqg7wXjjh+yUeMkP+5LS/pvO
QhmN7yoPJ6tKtGwexrcJ7FLc0eJSeakZ4lLfwuznsxe/moaJYBomBOAKuAaDoB4uL/wWL/z690vv
zL97Di0fQCsplEGg9AqUnIXWbklHKz5BG8Ef0CYWykS/w9D7YfTWDbQGX0A/e5oBV+WBPLgKruXC
NCbcDjMn/wHTUuFbT+BPYcpdmAvmEvai3BjRrIsVLwNoGdqM/liEypix8J2xWyglFaXcfvv5NvhL
kA1TWHAj/AiD28fhlq/gr/EHMCNmJq/DDY/hhodw8wT8iIJpBFzNg8vz4bK9Dz+4gOLARRQfRK+j
1Rj6OR+tKUQr8SK0Kvc3WwpBwZZM/mZmCZv28VP5XtnwOBa2zHZ/hr+PfrItJ58NWPlF4mJmWYV7
gpPKGZdcvIU9G4JxV+Aa/DJc9eCbb+8szS8MXTSeJiOyYGOQ762i/89x2cc2cd5xXN3w+aS1oGpz
5ZzRuRVjjI6tjEob4zWgVqGUhUYEEl4DIeQFqPPmJI7jxD7f5XzPPffuXGzn1Y6xkziYJG6IgRIS
UhiQMCiD0jAN6FbWirVaJ+2Pozom7aie/396nke/78vnwGkNtWpvDJr0x/sse9m9jqJdW/+wQ3+p
SMfQY8td6/6IHQpXDNTiMUeibdAIiEzX2WHjXDg3f34+Pdc3h2a0Rf1f38cmvaP1Q7gz4eiq4l7s
8rOK+n6LKnbwCofGEYkNwk5uWkwJqhJXo7Ge06M3M//Kaq/GrkbSYqRnrGeyK/utFrZ2Z0affqKt
6Er3XIzOdYnWUTBUkMjvfz8nUtlblHhPW/X8N9aHel1W/9ngxnB1TuTDiEs1qq9hMAxKxboDQdtp
KsaoABVpjoFYALIMwBs9kKjaCdfYliP6EoQioZ+kIGVrQCgKCpRd5mVewYMKLyj2/yimZJ8oh+1i
J6cGsU5y2D2DE6d9I0SKTFV+l69trRHruUZePwGs25EGtg5UA7KJbgm0v6UnrOVvuAr8GCn4JC/e
TfcyA0CzeK0dxgVZjIbtDIPXOKG7uADm2U7WQ77NDlobYJVxPZ/N44J8nV0yczwvyYY0n1U+e2S5
Rz8EX/GXwXl+XKDjVJyIl2o/rr9OR9ZoDVZ/D0N6jlcX5JQsP76+qdBfQ9YS9b462s34AMEQtF9i
rIu1bxNLF81asuZOIcgrwlPJ+kD5R/AbGc1cg/xDu4aAh+S05/O6K8fG9qOZ4l6jL6/Yuk5fsR1v
a1tovFk9VZVzqTJz+NR+tL9MNeDzFwfX/HYzvnqj/qohHSPrViL6KtrE6DkboBGADVBw2rvMhteK
Mm7EmdSh/D1yMaTKnUqwQ+hC1bhwS/sRFoRhths/C04Fse/M2iagrQxor+FA22M6ZS6Qi6VDAlrd
wMvNduMbcp43Wkb8o8zoC518k5qaQ6dvxK/fwBJMkhjG/UlPwhlvGKjurgrv6v1A3ckVskXUfh/a
Agma5JodGN8IXc0Yo79setcc1HGT26z5/5druS3MhrOJgWC8Nzk0PBhNd4+j3ePBsQyWoEd8E7gv
03SmNlU7dDRRFC3qL+jYweuLQR7TwhiDve1YuTnX/Hszp78tviVVy47e2pRrxHmFeMz/sPmWpYvA
0kV/tai7hT3FWCtsZd24n6EgbaATZVTumoWD17ZPbv9o/cCvuH3sYaqKyHfucRwsP3jsaMmJ4uN7
6na4tqDuXGJrLqavjOmvZFfh51b+KW+hDC1dWHAt2C4gs9K40qtMhya6RqIjvanBVDqVTmb6P+6U
rAIQWDmAugERwGr1Ra5N3jIi4GXcwJi4nNRfsy3bIEeK7cWRwlh+Kn9oT+bgpQNT5XM1C2j1fc+j
r7HHoc9i83hsPj1//tbHN2dn5rJzk3eGF6Kz6gPl3/w98Kn/pmfePdka9b546/fLEmnLgJoMpqRz
wmk11of2jgT/qf0c094081+B27y2hNHmTCP0gC+Mu7uORPK6HJKBr0q7yIRAX7egGtpD7yJjXIJN
wmEuZ46dgze5PnYQprmn7J/hBPc3doG867nX8pnj89KLNVOHp3Zd+mAsP7ENTeSFt6zFNrZtcWzF
P8w99n7x7r2FRUeKaosd652vN6P+kg1AN+XuhPubm2BDgIG07fmbCAiaAM8KMiZ0mZ55z1pmmi+T
s/xfwG31dvR237XB6cz0aPZs+kL6XCwbzqCxSx13n2CPXF+UfYnXXj1w5b3ZbbMbJlYnVsd/GX6d
e4ctJCvaGIpmGAZlmhlPmx8SBCZshjtLMN1h1hdkfVu4Ag+Xj5+8WvvDbqxO9lkUwbAaIcJH+aRw
W5yQelRUDYl9SeyuWQuZgbaE1zppLWv6lM74VNwbKu/YIVQbTaJJQP20qHC8KEh2ReI50a6yKoxw
E8wEmOTvC1btXYR9cgdetE2PQK7HzvaMw+s2bRnXy3whBGmREtr5QA4BPQE3zrhebEieuEs6hNMB
0I77DBwkBCpExLxpb8o1XpdtSXq7CZmUXcJJngYn4W4BbW2FvMeun6FM9Ugl62xvJ1Gfq33fOozg
1or627i+3CwHOljD83sQVu2BUVs6EIcqHwQKlET0zhOO116yp6WoIqmq2nFGuCzOqKmIKgOFVQDK
GyJhMMObgR93ws364kpYXloKGwBGAZKhcIqmAcWjJNLa400S4y3X3Rl3j7vbESwzwIjywAabk62C
JRy6E1nLFoIaBq0w60Vm/RWz/rKZy5VKFSLkTlBjPHoDAVI/HLeNs1k4w2kW9kvpbHiyczSWHE6m
Rm9N/jc0FOoK8TKQGTngfMd7KNBEFtN7wT60nm70tuENiH4GmPRXEX3mRaZ4DJXrP1kDC2wEBXnG
HuBYUcI4xbRYOzEtW1LmiMFJI3JaGpDCSlhUg8EQKieF6QfY94qZ135qitO9RCfuV6uDJcoRsVYi
JbRdoEUZcoKCqYZ3qwbnqFGYsiURFSThpIBqdkT7CNE+QZJIFgmzaiDIoJJPoBgMlPP670wkJBk/
TrSTgDCQg+YDEiMzYSYKEkTadZ7s9YRcalk4L/hrvgQcZctAGeOEBIduQk6ytXQjhbaRZGsT1mrm
K2DFMQzofaZqvl5w4kl2WjBp25B7YEoaDPcp4bDaLQjBoc7L4SfWsFGwZc6Ie9DJoP/nuMxjo7ju
ON4iZmeaSlSVgK5nyWzSKncQJAEKJMi00BrE6QaBwRRjp+UyYK+N1/aud72zc72ZN/N2jh3vrr1e
r70sEIO5T2MCOHEENE0krpSkUdJEatKESD1UXqOhUh/9ZzTSaPQ0v/l+P9/vL9WOQjvYwsNXo2IC
8EZFl578c+T9tosVYm/S5c0oWqR7M4x6Iq2oQU5XBYPhfR1qHAjETrwqqeyv6KSxq5oc/jmVQN0o
zvXGSwIJA3BYHE4yBdERJBKsCtA4AIg0ahbDmZvWw3Xb6uCmQIdFTfnu6RmUf8bk69MGvZ9T6Q2o
McKuk+sevP7Jr8crll9dcPB53XtMmxVd1vxi3cJfVD3FVD250/ux9xQ7J1tZXsaVq46uGq0eXTu+
8UbD2d1j7RMxRjhyUf1D4OwFlHsreNk9ni8X9w/kB3sOPoq2t+6y+EfircgA11XcmJ2fbkD+vSql
yNCQgtFeCqaIb7kR466OaSLXA6fhROAf4EuDUguDsBRQzZSmBwwVQkjULj/qCkpY7TKYlb6wGhHi
MUYSQIhwJUC/ANaKrZwSEaIxvjvWHG+Ivt6yPlorMZ1z5kkLAt5073u9I/OC848subDq2uqJrdeb
bzC//6L9q69ZTA9j3zVMcdfxpPt/xYFbX4/iqWU83yBF4KvkzcitzomO0+H/k/0H5ekleihbdg7Y
o+iQnbWypuOmsky6YBZLrHqb+oDWPqaG9VPGJQ6NwQMmi/P0aeO8McbpF+HIADsOh4HLAUe2RFNC
rWiruccIozhiCCAcx4JOhu3LQt0JfuP7QLsN7+jHtbfJlUFJmFRYXhMUwInkrwqB2cl1fDTOROPC
TrLEGj9DP+XQKwhcAJ+CipLSC5GBXzD836o4Z1FHCo9qHHpgPPgXe199Ry5wwBWtpMnIv7XdOcGu
mI7iQZBRcgNsGfU/aqcf+m5qN+EtfVT7ED7QmbDSCeLc7sQ2qU4NgValAzBdCaG9JWlIIqu3wC6Z
9SbTS2lttu69Bry5VKOxUV/GeT+ht5i77E4ulUyLafBZ1H+WLwuOzDhSSpRZJUEpPiIFafFrcP6K
zbAp9Bs4J2CppokM0yWr1Yhz3jpmlHsKA0w2bfWXWfw0nToDhywyx88UPInTHGCJqc7Uy5o3T2wE
LVpUj2qNcANiNmzWjS1BdV8YRgN7tAhUyAMeSDIjiyDRxVbRcXUN8CZxrbAzzs5Ga+wQh6JWMq1Y
8kFpVDjMD/F9khX3ixpQOBlImihLUAiIMd0IB3fWw5rGJhiqr4IzO2MwHiDa8Ko/GZiWM7JGDn1p
XsnkCkw2b36OX2H/TePJNCABdke9R/2NJqF0hTJc2JtnT6sX5EucagNXcdvc7ekacxPaa4s2oxjA
ybMf+3Da9772BcSTdIaHgiJx3aANNCor+TfEuJyUCflFMQZa1T2yV+E3H26hvOW0Vq3+roNdhDam
2jnUZkddwU3kpKIywpdAXj8J9isEQroIgcoCWq2ug82ByF5oNAS9xwm7O32dPnWAmuIp3tSH3DQ7
lzGtwJGRyO4TQUu0AFJN2d+d75X7A/vLTr4U3J8vlrPDxXO9l9yrTM84eu8ei+cSeH+fuq1iWsQv
ceJ/phq4xsgrvVKuQiEMT9i82ZUKo0rT36pGDd5kVFMzbbaHVvP96lDgHDhLGs4AqT5H9JKWhwTy
+CWfNliC5UA3cQHgVigNoFOOiHExKTKyALq7WOVJI0QZMdjWyDbQIdgeYdFeGFFIbHaBVo6HJAAy
JJy85ZT3GF3VPbPZ+yEXeXnHq5uW1C6p3bQ5xDTXruxeGHhjl51vDpKZ9akDxmCmMJh7ZHsslaf3
oX7Uz13uGXNGbebwgJN1gpZlDo+zDk5peLGO91ETNK6An4JjHFJdhTQ7K2Z2o4SxwZ2VZ1zoWiZ0
smxWK8Iy+aLnfH8BJYI55MK+wEm1CE3jHvJf0U6oRZWJKjEQ4SSwHaxSV4NtgCd244VQPRuHYW03
V017K+hVNPI+At4wtYoOo4SlcH1gDN4zmD/68CKTOvcmcgeCBWt46NzJ8mBxf66cQpZj92T68keL
V5jLPjkktkrtoWfbFyZXq1G1W0t6D3v83jVvOVwbaYcdgWd9U74rlw9NK2SP9YzZzKmSadlkK0yZ
uuUOOe+hBzYOunhtFvNMGi818eTzbJnegpaYzziM7ALHZhGyUIbLkJwm72g9MK8f1s7Acb1fG4Zn
yH0eIr1Hy8AsQgISDXBmph8f/S+NH/fe/Tuuvocrx/HzFcg1XTNtuXbW7LOyQ++cut9/PDvivnkG
TyrdsPt7SFl29LSWhVl9BFxV7xjMqHrSOIQYI06inhUg2fq4eHub1BRYL++Uu+SYxItEM0l5D6jV
6/zaFuo55M0zvVbOW0t7U+ha1IQEzuSzQkEaib+duMMzJm8IApk9WSG5Ot+OBojqg6i+xQDe1Lmw
vjVKuKAo0JSDBdrW0xm2aB20j5mn0ocyfTnGHkJjf2JxDT1gnHqX1SfgN9jP/hN+BMa5ROu+mu2V
0W1+TfZmet+u89il3ty9lU3L29ZV8E1iWIozTb5K3DgLtzyBO5/A7Yvxi1vvinukBbw3g+G9RZK3
wqtl15jLnF8SrzvRPp5J5E/I1wNldUgtaowZ1XlSHUlqCJx3whduhP/juFyD2rjuKJ64lrRpnenU
Exq0oitPMmnapK0Tt+krGJMYm9bmYWxiMOAXNmCZpwDxElq06LVXu3d3tdIiyRLiIUuWRXjGIGww
D9kE/Eix44xD2sZ106RJO8lM3U5m7dlkpos/3A937rf//Z9zfuewoYoq08Qel5S0jckUMP+p86Ys
N3VA/iCO5p1uykOf10f0Aw281WXjreIpqS01rpsqmjg+qlOPVq1mPdgi2iRvarg+Xj1aBQOpjs/I
GR7llsDniklVxHnPKmqxXnLUuoA55h3TU+j75CThwxwuvVAiIEQ7ZJu0DR0U69Da7ZzHroVuxi3v
KhNkgzLNhQapqOZcmKL7tW87L1HX5fyLyF+L9CodRQqb2Ui2aFpBG2gn9YTJZpWbZzthNMrSvuKW
tihOqFzSWwpGUkNJ8TLaTJWR2VgN2Rz5/V+lH4ladU28ZRD3v/ZV6ukRwyAhEB4Lb3dl/eVnD6Sn
xO/XxI/M575fOdkUWX8xedv9Dl2q9Awr7XRJjRgvrSnq6Aa2GRuyXLMsWZYItZVjSFYDKhV2wkLZ
rARlzs2gfpGzHxzS4E6F3UIxZi0YjQRmXQn2vKtPUPuYHpdbQNwJ9r1/oBPUBw7xCUxUy8kQU4hP
2z+wheVQ7u7BBUPgtHDSVcE2cmb2MXS88fGjZ1NuuVd6k1hwIbo0duOdGzMLi5PJC2sTX46s9n3i
/R+8A1aJ1bZbLSuNSd2iLnkwuXuiOFYcKkSimd4d6ejW7syOAqwjv66gvLC2rLAo40BxeU51RhPS
lPk7Yptm2+tC3y5tdn/B2dJ4aaxs+tC7pUuVf9LfQRpvmz66j1KqR3nfPpuyvMIFr2uvB65GZ8Zm
x8enorPRmYGV4F2k9677ww/RL0xf1P0La71VtVJypTSZP5V9Pju2I7CdznHmmvNa8w0l9SdqT56u
Oqwr0OXr93bsQjp2WnIOovnuPcEsLPhGOCd+MP7W2OHp8kT55dOLrYghudy9sh6son4oTfFEip+H
NKMNO8epOTrqDMmxEHCepy7KVrpDeREuwCX4NbhvvNawUjNzdDgPGd4bzMtHn9dt2/kmtjvz5Qpp
E9SBBmjgDKzeXefvYqw8yTOQpRlWAB5SsA3g5+zD9Jxz1ncphlw8NzwRXkDCcz1XltCkOalfxJrm
qqfKh5uDOn+Zv8x7ylUPXweltk4zgqughChaVK2gvlLaQv36NFqg+qZSZaFMoANztoHOLlTH6NlO
LGi9RKwZEet4yMloeAfnZABilRHdQZop3NpG1e47Suk00m7wHFTIV50mqhLTwmHOzzO8mufZUIyh
/QMo9FKh6Bolbhe94ncp8WlxMxpUzVji7T6soT8rKD0VROSclpsWhAzDY+sT/PLmfMq/hUVXDy/Q
boHvRTyqM8wS8wBjItS5GErK7C3+EIg2KL5B37FP4wE1fqa2p8hdxNfLlIrYGVLGMYZ2QQHjuQAz
wLLAQwWZAPTRPoh8rBT7GfEl59ddyy3qFcNs1eghZKSotzAXlTZlvSq9kIsZ8FZZrgOH4vsu7BF/
INWlJjPHjvQb+1sjplhXDL/cfZtAcIqQRSP7LLlVepKSNmssXRRj1JZ9UvjVHnGD9KIYSm2JtAdx
Hne1sc008oqyTgmancfzUOlvKpxu51owHnebfTafZYR4F38HT+UJ2oyj9g6csu4/QTV1yQitkVKU
0jNKex1VpGnlnH6Fh+tx++QZif99tCElBM5QbjgPlrlV3ww/7o/1xUKRWGgC6ZsQLkyik50z1fNY
83j50IFIYWS3L132q7ZGUK0Bp5z1RpST8kGGogj+gUlfH/rVR8tpG2+kcKWw0Y6SryjKHU2kBeuy
E8AM25nUlgdVa8UzJTO54Z10pjNPX1qKlJY07c9Bi0NHh09iI8c+OyC+sFN88sDakanqhO7tioFj
yMBRoaQIzW7bU1mAVeSVHMmpQ+pyf4s/p/nlr4S+32hLe2oFsxsheLvXj3JQoP1Y4CP3zSQK47K7
uhiWX++hMm6yDs7OWCDBvzb25q09SPbqWs19zcKMZzChTQwOD4cTSGTKOzmNLrbNl89ilYn0Bel7
y9KmpYxpXezA5LGLDXNIyziRWEA/Hf/z3RvY3Rv/GRI3w9tguXsOHzONt07oH1PTvYm0jZaUKVHL
BKEgrzArcz0De4C3y2vwtgldPInYXT3Ap+lRTpIiARTiiFLepVchD+QUguoZaxQIUFYny7kQpic0
2qf1+AW3V+6JHO/kNYwJdnWj4BTMULSAfeSPsW7K5nBgMqgDO1w/JO9gyKA1hl9vv2SI4cE2r97d
yOdyP4HbQQFVAZEaoG9FPd9iinpQQu7CoISBdEUj1+ExY+6uMDFufa8jQQwCH+kFHoC0Si+q0vdR
5RrpJaW0QVnbRlk1JgbyLMewao72sn1MDI7wY95x4azg9fMcJ8AgwseY5c9RMVv1EFXdUwFx5Dgo
pP4I1T8F+6wthM5wqGDvzzsqTB0maIGp9LpuOW5AGMf8Fz1DdHB9kA8HH15L2/gohTXRhB21ySxr
w4xW3EnQpFPmG7kbWCho09aBZoeRIAgb4ejulr6TynxjUEi7XdIG73Gs52ioKtIQqbvQvGBcbJ23
XIaiAvz9zPLQciyRiFxFIknfPVGBQuqsYw6LqtywL47CGNXrQjvFKPlPa9IWUFsDFp9Z0AdKAlkB
hPSBM71yWQzDs7Ibn6OidMIZpljZjbcq405QnI6X4cYutbGzW/9/jsv8uYnzjONNx7vethCmEGdW
K2aVTJujTGlKWyh0MgGmUCccNYYEfNQYg/GR2MKyZFmXV1rtavXuvVp5JVmS5QuDOIyNSW0w2Byp
SQkeCB1KSOlM2pCZDEnbX9rhJV0604W/4Nl59n0+3++nmfDK++Q3yYRZh7xeqryMmGVgNbOXpLcE
9/iauhs73j3obGmrdm/3Yd3bdzDb7Svf0tP7HBuHKop7J+rG2yYCk5hnhvrT18RNa31HZatpwx+V
nuKO0jkyZtBaj4S9je4TXBrViz0VCUXSVI1MKIbVDbER9CMJga+iUFSQZx85XctLvi7TDYS/dFmc
s59Ee/m0mFKx6U9FCX7bIQwPioN2frAgDthVTuUkADw4iNJcUMIY1C84+QbQAA6xIQZjrC3ThCvV
NFxDwlfMry6aJbPm4gvmkvPmEpsW0iIafROuwsc/Hfv7qS9vwS24IikZbRi7AV8/AZ+ZIZLAoFMk
Y4SSvkRMdmn1iU1pnEvGk0lCTsEbGvJvdFwYimeATOMx/kmBYwKWFth3RJuYEE3RQW/QaWb/V4qv
M3dVmi+3vNT+S5xjYrwVKCJn3wCrfgt/UmNxc/qbn+Oe2eDxcCpqNObKBz0yJQMJA3FFBw7rcf33
Wx3LS/5ZZpQa+qj2e/kBj19CR1Dhi0ti3m5ZYlwgODEGALmC43hWiPI2PipwPMEpMZUltSeGQ98w
f4PDlY8XF2rT7XrENlA/UlnckOo4XHl6tcKqTII+PjN1fx4unX5QXDAmYgXcXA8fd80FpnrGbO4F
33jYCCdb9Erdo+BABtYPlGRVUVRsMCtKScc1ATmBXkHPS8gc+gB9UlAtIcyhhtDLKwDT4rIlshwf
tz6RjfjBIXsT28WxcYzlAMcRoWObPzS/Tz4wa4vzk1/Owudsw3OpySNEikuHMySre7V21Rrr1xCt
VJRUVSd1K+VUBTPOi3+z30TPCrckBOjWTLvOyXHRmgRYngSxHt5rrwo3hQ75AqGQt6dzvbkVD+6n
2iIBQEX9YX/TG3jS2+csNELUVHGdyraNVo9WDdTmG7LncVlbgKtGZoYuDl22fQZ3wSXwr5nx3nF9
wqbkEFUXNY3Q40m6l6QT76YqsxjHyRrrUAQtQSRKi/2irDvu8sgX6B30mCBHEU7kAEvu7XYGwyzN
MFGWYemwO3CA57p21JtI1Ed30R3xCEfRvkAjHnbWmourzGWVZpnN/K55oc4sQfgexmIZFxVl2kGP
eKfbb62DGzbCl7ZCLNyNt73ZuGbvDzaZq/C2cnedz41tQ821j0jTDhfM78FZNs8U2IItbnB9IMsW
fOfa7kQs1B7SOzSfRmlPCQbEEuUikjupaOcd1xLjWlLNSP3JwczkZHGscNJIjRbPXHgIkXv/mLv3
Ilz6Q7h0BVy2Ai6t+MR9lE00GeUpzO1XFcoBrDQwCDmDzBRlyXAcQRdQuA49Cab4K3KeH5JHlZyl
glbJETLxHMBUy39ihBCmYi52f9x2gHXG/GyACcdYFgMUT8cJVuF0QBabZ7fd/imsMgX8/dnp62fv
QgTar/5ZzWJ6Rk5liAyXsY6VNvyGM1Fhdb+wgsU4VYk5uFTcsA42A3cpCNyK/ovLxpT95qKGhi5X
iI7ZfP6m/e9s271lz1vV5XSo2/1eq8/ldXs6lZh1GKAviMP5x8sWVs1UFF22fmaQG+IxMHwW3LBr
3RIVJQSqlUfooKx4HA07xc32V2RzM4+AAx4xZmctwaCtfQi9vRbwkkqGvCHB5zNI2tAMzQESnKVv
HVM7P/nFw9X/qbjdfCbK7KveuPIF8/mdm6IURnmjforwZnpGaXKA+SP9MILJQfFpukT5GOnkEeqA
KJc7zEVrxZqD+8QGO99FWVyhaVGOPMHGo19ZJH1Ydhbttwr5B9J94bY4b8G/FM0JOT7DYzojx1iC
KnVRSBitFNokjxAAAdYWtVYPCEZjDIa0KrgFh6yr4Bp2jv3u1O7TFX2urCfnhWvMMJ5KZwv9o/A1
2ILDcpjM5ZIpybDJkqgmCINLUgmyy6jR1ycwjhWVqLWIuGGoom4Qly3c70Lhj1FNyIojEtiDA6tX
0na3AOKsSMs2io3E6firq9f87NerNq2sWFu9IdRJdUcj/s5wEESxmIs7WEuYNYr5Hb2VVH1aROf7
6Y+jcBGNBUvDQoSlSLMXNd/gEfNFlAqJctAhJHk9ochJg0gomsUu+Fw/fi4z0qvoRkJLWyluiPfh
OuJDYYLLkiATGnGPmzZYh5td8F7z9HvH2vM2Sm3XanTAMyKl8BfxZ1/45hJ8pixBSxZsaaYn0E16
27p8LgqLhrqA0157MHvc4+jJ0yfYWRNdjR/obO/xshjd2ghq7a2u5GC3wztAj44R08U/XLlOfrBw
99JXUx8fOVPIGZg8KB4+Snwevuo+SbqPNefq5Vp+r29/s8ftq+/ZBnwWMLo7vB4mIFFCjxI2ME4F
Wi+R7Z88fY08fXXm3Pzx+eJsdkqe56e5Il0Mj/oGOocO9TmVdkwNSLtfI4C5FjEXlQZEKtrFh1jC
rfvSYbIvlGXz8ig/kM6PpDO4mlQVw3pL5txHZdrn8vUJIi+O8mNkna+6s6qlqrWxsa0e87aEnR2E
M+XOB8i8b4g5Ig/zh/Xj+cnC+yempp+w5cjykr+UJUoTalrJk3dS9/KfHca0XvH/JJd9bBPnHceF
in2Ptj9Qq3mDx+w8KlViLdvUvbSoRYx0E2WhXRpeHIeQhHh5wcQkpk5sc7F9ceKcfT4/Z+ecy+Wc
ix1j4hwObl7wCG5IgNCskKWkKGyF5Z+qontD69q/DnTZtIv21/Pn83vR76vPB/EmlkRBBqoZjP4F
2qOBHYUCXXB9TDeY48Q5053+gsZn9+iPuxdcE97Lzrz9ki1rG7aB3EHhaC3cF6oKtOPuX7cfO9to
t9a3HHGA9qMV/nJj5XE+U2WyZNqEIHLQzZ119cCh/z2zuAKVlzD6AVLO0EX0b90XWAHrZ+QFuKS5
1da+le6UJ2fNvpvRSn7q2qmWGb6JPLx08y64+YeLf1W2QWVL25cV9/H3Pi0r/AwdpqvIOtf7Xp8v
HAAhkj6g/gCq+2M/jDtwoTZ9Jk/Mtc56r0U3u9/3LK/sNaAKi6XaZvHs8Jyo7D1ofOvQyHSlqXK6
9nbrGrDfJz5dg39K359exWc+WZhfKaxMrEv/Qn+n1/xz50COEN1O6Ap6fQHcT3qozuiZyGnJOulM
d4ou3s11xJ2okj5xznoCmH/leHUXVHW5VxfL8VuHllvX0AJd4q5IM0MleeHaZjnPOp+NGsawbzDF
jN0IFvxJ3Cc2Sm9LINSL2G7TAKbhcgI+GVhPrebAor6Wqa6CG9uwjTJMdWM1rEPLYrFL7pvVzIoX
maTRh4U1BAnjnpCLcofV7/9uO+X2RkjjlxhJeYLOXlCz6+XOnxrNx6XJI6bjhVPX7Sugbdl7bxUu
8bdTi3hqMVu6NDWakbOT2amMPJxJfCzOJFLoMf2gd4kAwZRIJYwMRv1njyFWin6l7IHK89QjsoAH
Ljsm6vINcnXyOPolfbjV/A4wl7f/SN0G1efkn39Uji+Vr7V+jq7T17hisiheHBLE/6/j8tNhw8aL
+gP6NtrOtCJAOUM+CpJYALNgdaIl+1s8+85kTckObHNL3lXjlMxyF0wZLp+cyd6/uT3eogsy4RBs
szU56jvrnbVETTegOlsiFuPJ2sRorak8V1VqWgFNK+5HT2COm+TncH52dD53a7SQkXPZYl57xFlp
PnEbLdM3uqc6FltnGsdqQK5aqG/S8nhjPmeY0xforxnlTQRyyVh/v2lIjCdFmO2TfQXcN+Eea085
JDvfjA7Q79pOHgItVZ6aU1BrTs0+feHZtEH5MbWueRlAHoYMQpLxhgm8i/YyBAI2/X7azNgRICK+
IBWlKPU55jcuqKYwK2fjnfgAIfpGgkJQ7pujQHAyGxKMbiagOZuftiMrsqAdZaxOpfVn9JGMjucQ
y5puDhYGk8Mcu3neAHHMzJ+hcopWXg8rz2u/OhkbCtAexoFocXsiNhDncVbmkgum0VgyPsADNo6S
WcijkWgO5z6JXWUl4Wp6dvxabrYwM1PIX7gsfTA0zRe5kjatUmCcAGkfTxCQCHr9Adzn81KuqDPi
iDtEs2QXglqgkFE/stFnyLZOh9PT1tsKgjaqTAUN0Sbb5oiQUtxn6Iu1CyelYxO2Cz4J+JK9qTQc
jg/xAj4sXkpeE0tDU+J4sifmT3hEsPtu9RfKVvg4//DOCn73zvrEEzRLz/RNkpnuPFF0AE9uOMAa
BUqgRU17BZkpGUu5TQCUaCHChwBPxohOGKA15NXEt5cmkYdujdXx9QNtcc0MI6EgHTDmK0VzLaz2
nbBX420Wa6PlnMVh8R3TyLmbOY+O0GbvyTbQQZBeEnYJ/gskfqdJ+ZZH2R/+LLxEFomiZ6I9fRqM
NvHNTdBC1DTX4y11x1recgBH2Wu+V4wvviFkK01Hs9acMw+cMinLMCvmc1P4+PTtmc+LY4KUSGxi
YMPTzwzlCbNkxaWGrD3vyrvlQD56O1LKTM2B6Vlp7Z/wH561xgW8eb7m4jFUQdc6z9YA+0mi7GVt
tsR/f2KoXXrQ8di4vDyYXjYtj34oy1NAnh6aLMA0NRpI44HRriQhEkPOwbMJV9web4wBTt1yKP6+
sbzSWWs2NTW5G6phTcZ6tRnXlnUnZ7gvXOH5QcCxLJ+C9zDl25phLiIF061j6Cudsof5WyiPh2Vq
JDjoG7JKh1MgjsWi/QIc1DxkgAWJAaTt4lFySSpIYF4fdTMVu2FEfSGqvkGp9TofIpEfL34ofyCN
FMYnM1PStDSTKKK/0H88PX8QyA1iZRmkX9JVYqHduvBrdI0PupETteO3yOmAHExTOyIOndqtJ1uY
91pcGqJ36EOIZmOaBgxy6Xg+vja8nY9zGvWwSfZxTNnLPtweexRc9S0GC+dle9Y+ahOsUXvkbI/d
5/J3uNodDrvHSZ4HwS7KeRaiMnq/rg/VoTdx+m1UpouSqC8Ele+0cOFESIzsiPXownQoFMYJrwZQ
ZXr1db26TR/UNMFv4jCWjbP85hw3rMrenVufGEYT0rCEJ8VUIo2ydKpXIoDkGfAQ0N3jIQic8Hh6
nKiT9nBe7SyGe9M5bavqlo2vDUXsujiWYGM5QU7L4/mL2XyqAHiOQXGTqGdtTIcfhhgv7cTNmFrA
IuoN3TmWGOjF+UCuuxSQAxlKDIFYkKEY2Ef3UWG8/TRTV9HIuHsqmV3uTsZlDFMM0iAxSsdYGOfi
Aoez05y4aspGRa5/EIh8PJ2HqMQo31Ps8Ao9Rol4ON6TIAa9CRtvFjajfaNe+e7OrR8ZUokRcRiX
/kdy1fg2cd5hTe2d33XtprVLl5y78ybEtIlNXYsW1KlMrGhDZTBKoRRIQ8A4SQ2ulzQhdowdx875
7t779mufL/6IPzBxTCDNB6YQvKYhbQelmdIOuiFYlqqrtkr7Yqqmgx2T9qb7C9730fP8no/hXLIg
lYRCNDMAsqF4fx/VPeTvD9CDA/2xXrkPBuIBjHJ4KD+KUa557O7PG25+XBjNjunVplQ1MaWcA+ia
cnWBSotFeIrG1UE2t0LzAX5BGGeKEX0AL40WDXCx1ZYvz/x57L03ar9t0odTGT0blxrxFoRIUKy7
jXFLlq3HfJT1cOwHwefpgV3dz3fs7na5nPsOHepoDDIxlU2wehMGcOqtR4VKXI7LitSk5WR13DEu
jSBkgKSu1Fco+c734HVCkcs1Ss6JpTGKM58lzCdsk+yJsEFHUk79pzrQbaqsJahz6rQ2nsip542l
EpggA0IEUs02p016mrAesFl7MEcs8RNbRAwFKYM8CcvJ8si/by7OV6qgUjFKOQrxRjRL9+u9iR4E
YlFVGXIMyhFlSIWJRvyCpNOfwU/E32HLuzArXrQP2VhhVYdcJCj02V1hT+hYcL+z5UBLa5enu9fn
93gb8aBiNFbhVQZF4oPpQM63uGF22/hBPWgEjeP1rSfdiC0GKuFJvPxyGRw8SkzE1ZqxveTG+giQ
VpUcxNFrZxhRHnIoUNUofOqKgjNoEaPVNYA0Jak59CFc5OjAWOuvN/+19R3PRFAPJX3aL2XgIqFX
2P449STalcJJF8xHK3yFy+N5qXFqTIqCQ52it/VF8YUjr4p9Az3iEfvnp4Pr66cNFVtRLWllNInm
jKUCmCPdop+/96ZoLX9rq3gUUk+rTi1GJ0LlSI2rsaM84gDiJZajYkKME2iI5R3lO8UtdovCw4SM
wKjMKICHKjY2WVUcmFWtlnw9XsZeEVdVQxoBall83wSUGcbC4wiTt0nml4gSn2NSNKMH9C6jPd1l
hBKfl7pvVzINaZTTiio4Paolco4M0tNqAcSL8g2TwobBrkRqdAD1oK44YPwq6nLUbLP6VG6sVCnO
1ObeAwivMSTq+E9Ig6odNhN+2e+nlt6+Uls4OZ0+l7ggvwXPR874J3zjnZX9ly/OT14s1gt1vS5f
h5d76y3g4t7y5sepDTb5CWgFCS/qS4dpxJeYKWZ0KBNTBaBxMi5OQ5BhWTpKWvfJRNgnSl6H4N4H
t9l3kcxx2GtXoaJRKt5oCbqAxrQJNKGUUolhkDSU+b9Q5j7BJNkJmqn3zRwdP1JxZvdKHULnYHv/
y32dXZ2doNtmNdtY62uE9aj0jBqgFb82kGKwDTGzHOCLOajbdVZleYrhIAPpALlHJqx5cgMkNCGu
UBJKKxV0NtmEnQMVdUyNJiGASarWKc18SDBp4obtj8fffaVGe2acxRapTTgQbutp62k/4nEBn+AP
UZp1m9ioHUQROhHOMxXuQqwaHWYA+v+rIgd5esMu0ePtgj323TzxMml9lSMwapnSMsSXF8oNGSWn
FrWacgKhJEjGlXyVkieIlJgrUdCcJabZ0dAw7cu6UjtToGabM2ZyuFVWz9QqlxZgo/SK6I9QO2xy
MKkkNF1vmh6bKddGarnJ9HiyoJSUsjwPZ4PTXVOeUbfuAroz/mOLpKx1tpgY6uuF3V1Ui+xVIrQy
mBwymCuRyYg+CBhbTGBYhvaT1jdIqwm2CK3iIaUpliFEVVMQnUej2mkVFDOSihxI0uO6DpIZJW1Q
iqjDLC2Mw99D8xFwyaYuEx8df/foBO05fXDkBckpuAYP97v6OjztHcANvb2UavkI6yHpGbmHVkNS
TOYQo/MZLsvm2AJupMVhHtnT3CqHcKBxDWkdUQh+v0ccsHeT0CAkWZOTq4m3fGdtw3m9np+j829W
Z6dqZ2u1U+dPXKl8OPyxbD4MPzu08kPwUXNtrfUg9c2D69Y/RTc/ad3nsuz2pzYWLmxy7D7VWnct
gsNXfddXcDrcee7e2oZf1Y3qrGO2MnmhchWMXRm+tkLNRa74rtF9HxydPzDVNrE3v0M+CNvCbb4D
xzqcnh3Asz3YbH0BG39l3fw2euvCb7w3Vy2lci/boAlaXJGw1G/nc8jQk0aTosuGQd2G5i7WnKI5
8z/EAvtaLEdziNUYFNA7jT0pVGu8NTFfxUdbqFTL07rWqOKQiXPAJfREKOk79fF6eS7XNJeZTyzI
/4DLHUubwNKmM9+1ALXe/yPXFrp98569W9zAveVnwS32nc/qpU2OsDyoRDSwB7Y6KasVWYTRQ6OB
QvQ14R1uhs2zOp9g1ChYQ36ftNaTlp00i4/dLzWEhQhDWVnFWqt46NRzOefJY6D99cuBG/Y/vF9d
vORYuFJZ+RdlPuj9285r9M4PNk6uw2R3Rt0hd8BzzOtdda2Vu3+6e7nhJCl3QqtTtt4mdosd0E/D
Lvkw3KZaJLS+LltfIcJiH+yiozAWowJoQA/RKq9BBSI2xac4g0/BBAR8dpg37IhVYjwlMERgUGTt
1izpPACFlxwQQU2hcGjJcfrTkTd0TTG05OpY0Se1W+Yj1D/FT4RlepDxDXnCwNm8yb/Nvntn+vQv
HNvHW2bdi8B9NbD0IWV+sXb71gp9a/nvZ8375Tl4Objoqb86ES7JOkwqCA2j7Gj+HMZlvfjfjoZa
upL5H8nlH9rGecbxrUTnl0K7DeZNOm2njf1gZA0hbRrSbqSh6Uhp0oUsKaT5USdOHMexbEtVZEuy
fp306u7eO713pzudfliSLVmWospWbauO7eAsP7yFMZIyRiBhZZRtlIyxMhgdXLLbH3uT/nPcf8/L
832ez/P9GkXNPG83vwMfhq8ykTXPR+c65+ZPlI/gbWjf6WOvgoG3AntepN8qHm4cY5pHu2c2L24O
XQ9tPIkX6uJTR2Px7W/xho1QSDOYO7l/FDSsqormULU0MQHmoGQ+J3QYYYGbSeQSGb82qE3gkBrT
5BX7/fqN2Xp1qdH+sL5RQ3bZgw9tp1HUxmMO0vXV9kqnW6vZjWxW17S1xnyhipuozn5pCP0+2g/D
EZYJBQMpX5oVA/KI4c4GVBaHUESAqVDIP+rpA4FBdniMAO9n2OqTfTiMOYcMNc7gQOLeFS7vzAkZ
KZNuCRU+x4HMUwByKAUFxgJUH3WQ+j51hLLeoJ63Dpu7TbG3/uZ0fy7U6G+PdiaAv7OcWHEuLU91
Fl3NeqHdoddDK+e7zODim52tna3tQx/6l8F4h129Rq8Wu40OM9dZbKxNr5dX9CWizrrQFbrcQqqZ
0gbko8p+edge4VmJxWCc8t8eutq3+F7nVLkP96ELUY8XeDyRi/30UN5T8zF1703PXzx/Hf3d2Ae+
tqfunroASgOZITd9InzGfZYZOTswdioKgn39qQHnrj16dZ8LyoKBykCRDHGKiT/kbk3TmkKEYrT0
FK7jp0r+ybz539neBpKtr4jW9wjFJAU7ymgeb6hgvi3hpquIpqU5DJSQFId0DIU5Ysgp6wVurxBC
Ni7ATzyB4w7eatv25k6U/Uz5/XpsPl0W2+paoYQr+VodZCmNbIYiAFnAxHvAnrGR4UsDMRC9cIJ7
23lmUK96XGMzwXqiBWCTu/M5uWlRZG6xrfaUpRmxSuq9TCUpiCAWZMBjUdZoVc6oKqPKpWwzP52p
Fev1em2mUW4ZhXyrtJpv6TW19HSZm48Xev9MdVAT29D9NVRxpoO2H4s/5bczR5CboOLryh7NzWSG
K95mqBlYSC7hDbRmrNRWq4tzHywAZU4iGn+B76W7DK5K0xXatHF3WdLPYn9+v+HHIZlVAK8Kqkpj
3VYpY1xymTt52+0WxooL6ZqkOpW9ttQPBOub1lYavaJYjC2iqVB2ZrkpRGTQqSyqi10EWIk0J9mz
07dv/J2J8USACwtAmEGGRt/rwZJepBOQ5WLw2MCR0cOXQPDseaL0/iNzm++5+q77H5q9qpSv0nIb
zxbJfSuhJpMVDUNJF2o0eXnZoA0phwxG3LQ1e4yUweaYPmNUjcggGlO0uKtJjP7jhS330V1pE3dR
SyrjIsqQcQDmFoov5UXdSRwYkgUARS4lMCyMoRg+njidHIoDgeMFRLNKLBNhMKdAmf2XxdrXrK+u
bl/eN3e1fm3m5uyN+U9XTFu+lV8xrgOclfQsneFzSYNJGOGsPwP4kUz+Vy6BS6s8CYkSOeF0JZfG
mssEKCtOp1uKA/3nDppxqsKXz0AcSWyjJGrClJRyvgOHEpFkMj55YeJAfCQ6EOg7Zn3DDgMwyI5b
W60v7O9SsJAqJSqvmy/ZrTce7Rj6ZHwNao6Uerq4pw6EDNJUOtvz/KMDHjIyjxzIhnRVVJwyL4kS
Hee4mMgch24YgyDGQjaSwIT8Mpv1lc/Xj67uum0B82sWb//YBDfNZ1b+vd/cbeeKcCbeJiavzKmc
EtCHjeHcuAZVoPZgEg80ppzO4ywGv6HM56hl8kEG0iRNcZQpJJMfpxCwcYmw6HOehsNxHwuI/pCj
Q+qENs7Iyex4ftgE1pK9s6t5qDxy+Vr379dM5/Ra/betj0G1qy+26SJXeJrBvMY5wyeHMjEZILI/
Ci2T8hozRX1C1kIms+Jsig2pnp4Ra1JDBhuUoMoIOzGSRBJ1yFwKzAj0wgAbinndwyes3f973R7u
9/xy4BXS4IjACizhpwB4geQKZ2QirXhdoflz/zxgvhjcCK2Gln5oTey3mKHjgI+wEnTCpKREXNbB
R4z1mvkZO83miRBxdUJ1ayAakRXWlVYl4kVAWlI10UX2WLv8+GIvuWgGXeox5BzOYbBIbaJFqYDX
0Zq0jluoLGUwmKUyYcymaIhSAmSi4hk4xkehgxMEQvmYHikHmQdbbxya8959sHKtVAOlGb1SoPNc
PmowcX1UP6kDISfks3S60sAaypMtcLRQU7qMS6guLZKqTSldca1TRkqGCdKaJ2XYVJyfFAfhUPRC
6P2Qz+8btbZZB+3mT6zX/vDSlXenwo7SZCleYitsIzmfAlEpCemklBSSTPyQZD0D3eiwUwwGpUnS
Okn2u9I3bLqeVgxXQ53W8zmQIbQz6NzArVc/Z96+7x1znx8+5ZgYjYzH4+DSWHx8kk6R9Moxeqqa
7MDZVIk3RCBHJZajU6QMyxw/KZ083Ie83iBZFBiV8KRLLCBDJ2DIynlckB1X5O7UfKPTePCZ+az5
gvVtc4fdcpgvCzLxLqqDVcNqSPXKQTmuPqHqz9XHrd5iXsKGa4O6iz/l/0jGaHlevOyUCaMRjbgI
N8G7BUc/HGUDETFsJ0RQY4wSV2NqdOrYwrbr1neXftTZ2f5Feam8Uf3938yYffrXheu5W0Ct/j/t
ABL/jJyZGpOIlIGVHoKSepNxlFyVcZKIjgiHjYiSlRqOjZCMkY8IyAbOBu8GygabBomQk4uWG5GI
j4aHGoSHiIWJHniKZYJtf3Z9GYGBgXqCcIh/h32EfoiAiH6EeoR2hHeBc39uGImG+zn8VPsP++WE
eYF1gHIZdFd7cIaGd3B6en2AWHQYh4CBi38bbnWSmX0ffpiEnqUaoZWfoJ4ekY2RjpGPmY4YgcWx
hpgbmZKVk5KVq72nwaHJCKPIlbalGqGEq3y2HvsG97h7rlv3Dz33ZRmHmIWXgpVJqBh2kQWBjISQ
khqQlQUO+qIU+jIV3WEUHQplbmRzdHJlYW0NZW5kb2JqDTE2IDAgb2JqDTw8IA0vVHlwZSAvRm9u
dERlc2NyaXB0b3IgDS9Bc2NlbnQgMCANL0NhcEhlaWdodCAwIA0vRGVzY2VudCAwIA0vRmxhZ3Mg
NCANL0ZvbnRCQm94IFsgMCAtMjI3IDExODcgODEzIF0gDS9Gb250TmFtZSAvRUVGRlBHK1dQLlR5
cG9ncmFwaGljU3ltYm9sc2IwNzUgDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgMCANL0NoYXJTZXQg
KC9HNCkNL0ZvbnRGaWxlMyAxNyAwIFIgDT4+IA1lbmRvYmoNMTcgMCBvYmoNPDwgL0ZpbHRlciAv
RmxhdGVEZWNvZGUgL0xlbmd0aCAyMzAgL1N1YnR5cGUgL1R5cGUxQyA+PiANc3RyZWFtDQpIiWJk
YGFiYGRkVHR1dXMLcNcOD9ALqSzITy9KLMjITA6uzE3KzylOMjA3BSmy/CHD9EOW+Ycoy29JHub5
PCw/5HjEun+Xy7As/nmQVW4B4//ubgjJw/49VeB7Bv/3bMHu7+uFGFgYGZlNPJPcTXwTk4vyc1NT
MhPj3fLzSiAWpRbFm+gZxocHxGPajUMQlysZGBhZGBjbGZiAFtp38/20+XHl+wNR95KgmDi5mJjg
Ercez66gxTE7OWJ3Fh05J3V28ZGdu+R27jqy6HzPha6jJTtjOXbGLgpyl+pm5wMIMAAq9GgiCmVu
ZHN0cmVhbQ1lbmRvYmoNMTggMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2Vu
dCAwIA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50IDAgDS9GbGFncyA2OCANL0ZvbnRCQm94IFsgLTIx
MyAtMjU2IDEwMTQgOTA3IF0gDS9Gb250TmFtZSAvRUVGR0NLK0dhcmFtb25kLkl0YWxpYzA3NSAN
L0l0YWxpY0FuZ2xlIC0xMiANL1N0ZW1WIDAgDS9DaGFyU2V0ICgvRzcyL0c4OS9HODEvRzE1L0c3
My9HNDAvRzkwL0c4Mi9HNzQvRzU4L0c4My9HNTAvRzc1L0c1MS9HNzYvRzY4L0c4NS9HNDRcDS9H
My9HNjkvRzg2L0c1My9HNzAvRzI5L0c1NC9HODcvRzc5L0c3MSkNL0ZvbnRGaWxlMyAxOSAwIFIg
DT4+IA1lbmRvYmoNMTkgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA3Njgx
IC9TdWJ0eXBlIC9UeXBlMUMgPj4gDXN0cmVhbQ0KSIlsU31QE+kZzwJZthbw69CwwY2tY3X0tKBg
oJ698wNXUPRQvJPzEEUR8TAQAiHEhLBh2exms5vNhs0XIQRCQoTLQTTnx2HV02P0pvasvR5jb+bG
OXsz17/aaf+4xVk6bWzn+lf/eJ553+ed3/u+v+f3/ABZVoYMAAC4omI/uvfgZvRMx5lLbZpzWys7
z7S2nC1Sl746rVhQZyyUZS7kZ1lyMqStOZl/z8laKM9ZtVi5GC6E1hRm75YjYdkBK/Yvmv7fIidb
nFomPly6IFvuKlT9foVMBQBZ2Utyl61cVVCo+vn6jZu3Fpeoy994c0/FgYOHa2o1ehJVb0PLytGy
YrS4FFVvR0uK0PIitGwbqi5BS8vQsu1oaRGqLkVLi1H1DnRHulKKlpSg29EdadAOtHQ7qi5Ct5Wj
pSVomRpVl6Pq4uo2TVtnT3tTw5aGH7k1/Jfbj9v/Q1kG5GbKlsrWyDbKXpdtA0qBX8n2QUdkNRnH
M+oAGeAH7EAIcAA+gAcGgSAwAnCABwgAw8AYYANowAm4AQEYBSiABVyAFxgCwgAJMLI16VbLsmSg
7KhsLiOWeSrrPfnz7BjkX/JDTl1uXV7u0v3Lfrn89MqfvVaRX5b/7er1q+8VmOH3lbnK54WfIr9Y
vJmnyVsrDWZ9fvWjMWFwKhqdGIpDwzF3dAz29Q5pxpCzk/p4FJ70XYlMIsPDIWHMEbWPWUJdUPyi
70IjXKOtevct5N3du49sOoPFFXlrRe/Ls/kfeqOhMBIKjQtxZoKK9IX1ULhT6NTBGkyr70b0eq21
1dFu73R3hyDDMBaJw3S2VPnP1fkTnsjIK2DEO+GI2yNY2ACFu4WuTrgFa9MbEL1Bh11SdnQIIb1K
P9L3H1zey0Wx+3E+yzOC0z8j7o2IK71/eiT+ReHkuSn+4ZS4S8GPc9POWxBH84OwMCBgPILxTdwh
7jCn8LNBZwgRc0FxI/icenmckVNBH+VXCnYvPeSgeqyNpmr8HNZq0UFdBqfLrBr4aGDUB9ujVMAF
s6QbH0L0rJExMRCO0axZ1UtZ6D4G6gBbwSrwLbAW7AGbQVM6dOBm0mgz23upAtyGkZcJu5EwWLt1
0nJFt7TEpjHtxI4RrQUY3Uf1I4nvOV58XSW+zf+VE9gYF/b4gn5f9O70i09dCryxp6JtPWkmemyd
pBFvtzSnL8bsuK2dMBJ9kNFAM0YV5ZQ7GF6AWQ8zOgWniAmzD+n1avh65hT1Dnl4oH7ggK2EqbQp
DHY5ZTRTmNJm76ctDuwY3oR3m4/1n8Zba6VbCnv6OySMs7iTQPyYD/dSfjJCJRg3NURHGJeNp52M
uIVXJB3ycTBpv85+Mgj5AywbUn0z+FX8t7Oziav34/NQBKQ8AiUo8Zb2tSelSojau56WCpXSBvA0
KK0Ai8BNoNQO1oE7mBJKfjX7e+5zjzw4zvKTqrTAP8SS+WFulBvh73PT7qCfZ3iXy8t7Qk9i4msp
cWdC3DcpHvpMvKbg5uSswAge2Ed4+lyIkW/mjjOQFewAMcrMGHmH3xlgQ5AIgWI1KJaBf6wFKYuO
blGesF9Mk+/vt1pw00CPVvpJg9QmLVm8qdBIa007jTDpsDEkErROEXftV/AJ2wjJNClIiqBxpQ4k
Ne9RFUrpTU5eD5JmWtuppbXKZHowvxXXLHyd/8T3dOIrJPaHxLMbXw+N337w/M+x2MPEdzdmgrOe
BxwUDDmco6oIE3IEGHENJf608h/SKujZxhmpQNoFH7GgujcQ3a7mPe8fqEdrqw8frz5a1Yh2Qjq0
wrJfuePXozf2qSpuHp1rmIeO/O2SmCeuS3tCTC5+kD/WFbocHAhak5b7pgA+QkfZFKOYD9wZigY/
jqQSydk7j64/TTxLzEd/5/sMisx7nj6G5/AHlx8gvffNSWxYd1M7rYlrYi2Rc8GmQONgg6PCjhqr
LlRdOFZfX1Nfc2p7owRCjRLUtW4LvD5YNPkWEmycqr97AkprtpCK3c7nGY7hmS/YW1xMCDt97kEv
6xyM+G45Y6EXCXEDd4W/5p51Cq6PPV86BD7l/xKKiCvYa/JJscD3YgZ22jmbkLaqkdOxEGmlnb2q
OrCLkptAnOpjejmI54J8FKGEq/QXyicPaOaWapa6Tz9iIlSQFpjH1EPLvW7W5qJc9qdnFclL4zqP
OdI+fNF/Hgo08eeb4Xa7HjchuhJMa+4waAv6zZdNXcZ+zIrjxPnWU9p3ujvMrf0tVBXWbMMYK2Vk
2vl6rpU38hCfzTJudgixhRP2WaUQoNlR1W/4pDA2dHcsNTGVSExGU8OfQEMJ/vo9ONk3051C9MnO
K22RjtGLoXP+Jv9xVwWjo3SklujT9b16xJA2sal4kVDUSi6igdCQxgKbgdTbukmdzUhYILKdMlhg
jLcKBOLBx4hpapqM2PwDkIXGbTCWTiRiPEdXK6UT4OFD9H7l7fQA6uau5weDHO9XCdQoOzl4NR0j
Ad7JsQzLON3zQXHT9MJyRVjc6RUz78ABNszFEO47uUB6rV4EE8wek3sPe8plSveft/E87GA41oMM
OtxpXSHq5g16VjkboxlBJd4FU+DcbRxLqVLmaf1k+5XWsQ+8zZDnvEujh1FddV0NcvLtnTVS5tHg
pW8khbhBMvl1oy3x+vjJWEvUOG74EJshQwMRIkYSjQpdC9245xjdpJTWgQdBDMQJmlD2c4QQ/DfH
1RrbtnVGgcKyOOzH0AzeJDqlMaQ/uhUJ2rRD92hWr1nrLejivJDGkl/xI47jVJZs6y1RokRRpChS
IilK1MN6S7Flyw9FdmQ7djLn0TQ1mrRJgwbJhm0Ftg7FNgwdRgdMgMm999/9dc493znf94EMEwpy
dJqeD2zUhU5SiSCa0y31fITyQ1cP/0s6Jq4ouhwq7OSOYORYQCcVFCbpiK+3HnMEQoA4hVEYNO2c
xRbwRW8ZL+EAbSddWP0L3YQLIox2EmlGLCSlaxkaIs+++R6pVveQg4ij/ox7SMrdQrEkw4Ihf726
IVK+rd/dMN3kscgcZ9HTHSBKYgQOmaTX3BKAveMdV1rkSXQKX6QmiTK9Fi7T89HF1FSkmCzmFxcz
uQCXuhCbiSwC0XJwZgq8oV/vqkDdi62Te6h24pSnz/Gtl+BNsdCUIhK+BBHcf6FtVT2nrziqBFBp
XMaXgrXoJaGUSKbzudx87jLA1zVcANO+hDcGYTmkZFuwz5uW9Zf3ir0KW9myYvoQQPP47EXwSmQ1
tQxlqqX56ky1tJAuRWrhFXaV+or4yvj1INGHDSMaR49j0K41EibSFgCmXVXbGoTmTBltWjs5HB70
H/Qdn+g9DfR164/+BuwNDoQGIW5g9ld/kICpo2l19EwQiYxOqoG0itcgYNBAGfXgy+da205Ab+2X
vjskvdS8b59Q2tvCynmysBAhq59GyERup6fvbvhG7N/dIDWtZuWzRI6MUzmPYr5RfBW9jnN4zJvG
lX5MhpFe3AsNebT4hN/kht2oB7F4DITWK31HgUnP+00yDanC26A9co8EyA7KUanXIzXIXAQCg7lU
PMEL2QvpXDob5mKTycJs5dqtR18K9cNHgap8ZvuHMuZW4P6fwbQ37gpDFmEsMhiCKReNBIklBV9H
VaGA9cY09SEh+7hR3EUwVJAI+lhcOSxHMFvdvSrniNOGAHbYPdoLnsNeQaQfQ9gbeKcT1MlzxWw+
mUmnP3kkNohQNBpPT04B9x6WVwWQJgJYoJ57MGfixjmF20HRcAtMWekJxhdR0HXzCRBP3KZk4ieN
Bp8VQyA3hvpwv8YziuhgnX3cPG7oUPV2n+2TEtLnigmt2Qg7YZPTBiOY1KKASRtugWySTeY7R+it
IM8xdeTi6+LvFZFQOj8zx7HZQmVtMpFIprJCKBzhBPHv26BC/IH40lwlO8XFlQwTEPwJN20PGoI2
Gq5fjw+mJ3jg4mP5xcZKI/GXm+RMM9bRbug3G+zK82MHfiHtkl6Q/vMUUpzp7j8tGSROQqWEzNXo
dpD25qyciMsoKsCD/nDgo4D4XERsVSzJ/fMe1GrWjSkJL+K0mM0m44ReN9S//0XpRekNDEWcVhh4
X2jktmW8+FgQv5HRi1SGBy/Jr8qJGBZ3x/EgGnQF3fUBbdw/4TP5bcEdPz3JPKGaGDaIUzZ+nsuF
hCwdo0KUQAjuCEwPKFDCi6OQz4M5UJPboGiT3h392fghQ6fSoDarrCprh20INuEehZfGWRwq1JWL
Z2sbhVkuyrIMHwyxLgZlPZYPNIOnO/tVgyMjRsCum0D1zbCDZj0tKOPlIiBHTzJFKH5JmGJjjMBn
+FkmHptJrsJ2q9GkP3Hw0O9a263WgbFDGr1Lg50jAJ2ZYlwtFs4uIGnAI2D5GXCJX09ch8p/K9+d
Xb3xxY1b12vXV66UV7O385uxGpUgooTgE3ABE7x12k/9z042TdLRoMCH6GJqdeHLv65vhKP1ib8y
vc7zk+XijcIDBb9E5zgw5UlaUxASMgd1lI4YxwzuHn3/6OBIR6f6SNe73QeH243dgK4NVn0AjrIm
HoZCcAyNUywhUEn628jq3d3wrMkUHmXP+gFzI11IEhXyJqUUiBr5kCJgw3unJfmbkl2BjppPag5I
cum/CvFH4vE//XNtU4gq50uldFGoLwNsksoTaWdyAiici5wZAF/Xv9K9F+rZe/inB95Svf9r9U96
AN2JHni4eUDDJyd2doLCNDjPLQnr0FXxiHhq+x/Zz7NbyU0ln6RTcZDHwnCsHtpS627phaY0kWEz
0ZX8Wm3zzuZW5UpqbvnT+c8K94H0Fb62DMaxKCxAzoiFMVFWwujRO/q06s5jba9Jzx09oOvRdRtO
WY8D1iPIoBk0MlbBCQn1X0hSO/yJ7a+ffK/JzaIcynsDWAwpuHNoDGNRtl6OO43fqtWoj6tfVUnf
BzqkXbo9PwdHmAkGgVikjrHO+UJ0ulgtVy9Xt4B4hKK4lmSj127WDHepD3Z19ukAbV+/42zzeT2f
sbQYio7aFrgR3co9hPJfLD5Yu3f5s8qV0kypVMnXctPRKa5AFYkCnBoHMtqw5jyoxyxOJ4Q4HJid
chMIZWd3MIu5J2NP4Kb/iXeZMJMNzSgp2s8EwXiVyUdAFg8hHGThz0f6wkZGwVwQ5cSD0EJKGW0M
ERwZorx63O7FAFR+QCJflu5ZjiF96LiyvjoNOUak5qe/VAT4PP3x7X+LzysjaAgNetr3tb3degLo
OzFg1jajLpJGWnCaYGgwGVnJ3Idy92IbbNliGdcODx5++7ft73QBw6puW1+z3sKl7S2mIlK9Bm5F
7xTvQYnq1LXFu5U7yzfWNlbXa3NLuVq2Ei7vcPakHYIzbo6N7xjg8LO2pjwxFZ0r3l65eXvzj5sP
K48zj4D/c1z2sU0cZhjfV9htVdGmLZJ9rs5MrB1dt7WMUkpXKihjiKhFhEBJE+XLiWMcGyfB8dfZ
5/PZZ/vOzvnOZ5/PH8fFju2LcexAEqckS5eFtFkRY6W0UqGbUNHUjW3apEnTejDzxy78e9JJd8/z
Ps/7ewufpVYFMI8X4ALkzns4RPFnDDPCRrvBrB9wjJo6ew/0vTJy1NEB2NvRfgtoZicyLigDXwjk
H5u9LkdludXV7mvvAHuTRsEKZZzZgEhlSI5KxPMpkU8LuXQ2L5SEIl/haoC4jeT4aEbjPNxz5PVj
QH9vt6NTc86SnbVqLQ335m3wIrOYWoG4K9w8fzG/XLhSvPKZ3KJaW5upMmxRKGan+SJXZopUnax4
imNAycIbdOBQQG83QK5h+6jNs69DheHj/kGfDjmDtGHKV+Y2WqfCleTihWn2ojgnZZJKvZfFaSVk
EsCVY1IVFEJpLANhvI9Vdg3pwqxOg36oXfcLc5uzCzNu/Wjz6807j77aygp8jNVIRXhE1Ca8LBrz
A7AgBHIaqZatzmnn6pU16UPpRvnjqTt/l/+nYvNMkZFuyLRKuJ5ZScxgZCCKK/QYDkTdGo8hSnVo
qQuTCsgpdRXNUICs3la5X/vz3OfF1dpqY2320vzFK+UCJzFzVIOsoyUbULbyVhsIhzwopkwxEvRQ
LhKOK85xmIAXiQzOK7ljMNo7iUZ8YYyAUYfTeh6xwmbnEADrHCftrzsO+noIuBxT/YVgFJtyMXVA
ITcQIVHCCzX3bDM1t7/SvEM4Q96wX40Z8POE+3CTVZl3mw6Z2kfadW919xmNBuugB/BZz4YGNaf0
ySmb1iGiBVKiypwo8luCfSmbOlo7GyOSZwog6DDLgQk6GU9ALJtLlVIzqSVpsxFgnaKloq+rsHRA
xMsAXgyVZsAFdoFbgMSNwkppoTxfrpamxUyBL/ONTD0uKb7XfLP2gqeMS1RKUS0XA7IcRTFakmWj
nIa2R304iJM4TkBY2B8NUR5ynDYmEAqNYTRQ7Od6usFd53a/uRc6/tKRzv2wHjvntjoBPBDCfKBN
sFat0ILjknPWc994a3BFB/xmuNh9HBzBLfB5CB4dtw5PWN2D3tMIgJzqDHVqXjhGJ3Tag9mT4kBB
N22sjNZRMThFTlGVbFkqLlflJzblrruKIPL3Zam1Qhd5cYpjs9L0cmEpu8hdBop/4j/cAOt4yZOH
ENHFTSgRtKE2q2187IT5OcD8E/hQJ2hhrRkHlLYLqEhuxXnHo3ut82d/PfEBwhEpMhHmiXxICgOR
xqWopNl8LyGuazfE+lQ2D/A8IxTAuuuSfh4am+6o7p0fFsxpa6bL0zb+6rDObnZMwHYXghEEDhNu
0kNZOKvgeNyJ1x787KlvfNnKlOVv5m4lCpSaJVPRNBVyqsbbTjZfDox7h9ydasuz5hdNB0YOWPZZ
fs6l0xdy5b/K4O371377Tm0pt0DNKjGdtgBFC9/XDh5wvaD/IXT2B3373m7rOjYwYHABrrMjAYvG
6mBSqNaVwwQRZJkEl4CS8TSTU7iEUzgjEUqhOTfn58Jx5Uk2K1aWNlbkr63KLwFL8vem/nETrIdK
WBryp71xWGl1P4GGTM5h89DAUN8bL+9tPukym4/1PtPz9LlfwkN+R8CLhYFQACXdGrePiuPaIBNK
cGCMySVnoE/kXzFsLBnj1PLsw3cX5W+18NN0jgOZCE0wUJgOTHpj47SNmUhuabRvS6Jaaz4xJYiQ
IOSThclCRPRnESAHx2EXOBqw2R0QhthCZspBwiySBpBMUCwpnN/zqK81gmAkrhmxT8Au7zmLeWTM
+Cai2rh97XcfLd9cWivMKxzDh+JBgPXRGAYanB36VyECQ61OvW7PwP7ug8gobHGaAna/J4ABdj02
5gHxWJgmoJiSbJpKkKlYOlnkKmJdqkuVWvEy8M42u9EyNNQ/3Ndr6rIq75gU9e1wjMO0WHLrxFy7
/K9P5Z2QvFd+X6jyJTavjnEUGwcpkiU4BR+273gw+FTLd1rp8ufkjegSpV72bTM91xIaP/528wmo
ubP5b+vRgR+daGrUZ1+caHMOwA61vddndoIxV8t0JTU9q12rLDcaqwDPUZOsNh0Z142aLTZ1r85s
dQWGxofdBhRQVCMmNGiAige1IZaIc2BlXYb+K0eg+sf1e/V/Xpf3r8rfrn0y+1HpRm4TmGSiDANy
yprmIB83lupPP57fPz747sNjrTGSCdNQhApPEpSR7Dj9WvMrOKlcTxRB4lGMypbL9bpCG/P1BWlh
Zn6qnuVpbpJTOppmoqwm7WURFMSifjIIRfxhFEcc7R6dz3Gi+bQKMSIGryHOxNkY+8EX1+/dvHvz
7vtXr1SqYpWTqAIpBHkUyCAMAoNe0kdgUHgMM3j63D26Z482d/246VaF0ZYg5acD0ByzfvXWfxYj
KrvB1Nd7xqgbMunsgNc+ERpVyHmSxbU4G2ITYE24Wr0NyaB8a11WZyQ2T/GKP1E+A8bJ+NZ8xoI0
PolFfEFvsNfc3Xn6yGs7Ow+N9R1utrQ1t51qtgRgZWngQARGo34N5onGbFpSudxokKG5eB7KNS7d
35R3FK5uXTx/a9kutz/sevD71ubunqb2+S1/n3z+p+27NG/1X2iYtCOL8PUvwPcyfyjegUqf1q43
1rkUl04Jc8uNy8r6uviusEqtkAuOqh6o6bJv7FGG/pHv0Zn/d1y+sU2cdxxn0ZKetKmVtnpyztJ5
0jSpW9uNdpkqRiOY2g0aKlhaE7oSDKYkaYhx4r9n+3IXn30++2zfxb7znc///8XGsR1KTEwISSiY
Ukq3CMFQNWDS1KnriqZJezNdouuLnXn9PG+e3/P7fr+fr2qKtSUwKIEU/NVINVRJVevXbmw+2ZA0
wKbUX5Z2PQQrZBHNQHMpND6r/NmkfUx/eFD3kxNyPzAh9zh/dRDsBnLzW1xVZZeiK7EinYkozsAI
SpMRmFiUjvF8PMfX/i2J6uSSeDHR5srcAl8B4mW2K+XuTe6fyiHDLTy4ImnFltgW2scxg2cC8yve
gQYsKEoQNEn55rFYSFTzMYHnoUbp8YL0XLP+KNNh60JbrIl5gOPCEV4b4pPhvEZ0xTAfSGK9ZAD1
maGAm3R7YbfeM01iQK1I03EtlUhTBU2072KohbeQjunSWEUPVEYTI38AR73H3ccg17Hpox++N/Hu
ab1+Qj9+2jqOA6bXj2FmDeygY3atjTVzJsE8clJ+5rD8xpwieB8C+F0khoM0Lnh7iVw+WNIUqUIo
oxQ0xbKoKKYOhgKBIERb4AiK+0KExkrJh5jes5YQBWtphzMCa8ajfZEozdJdS9v5ZqdP9eetq/eq
D4Dz98U7HbBBfuS5AAWyniyStuUdSUdiUjwZ0ykKQZwhi8Yg/3hC3mXav0f2qwlHEA4iAOWhFLuy
sojog0rumu8C3aQabF0sxS8v3tnsavOx9GjHroKdDhi2BwjjqaODZyh1ZqmxtvbJ2o3WcjNfTJTj
VSZDJJQeAbBe2oeDaBgP4BDxweyI9S3rAbsOHhuRn1UHnIKY/ah2q1/qkQyPpefXr11cWlEWr0qV
8bITyLk5uxU85zM7ndCc20lYFVxC5728P+4vhS55Up44GkFDc34MNxqHfzEg7x6QX9HJ37EfcRx2
nULtAE64SasGRhjWp/WyJCeAwnw6loMW765JP/qTNHxPmlLHMkySZqMpdZSMoyL0lIp7pXdVDapy
Lj+cMPIOwc/PiWQ6Ug/VxGoNKOb4+ipYx9etW5Dxa/eDDvhFYWvlDrRya2vxK3qZWsRLTqAEC1Yz
CCt15SnokVhkOmRJWRv2OpJThsLgtFtBVQxH3QDq9DusoPftxGDjxQs/T+0PjgBjng/tExA8NmnU
2wDryRNzxzU6Q6I6rZ2pzjZXwGIsJ6QgPpmMZZ5ivGn7uzs51Tt9M5GhUO9cH61kL196Qt0MZ2mx
LBT4bGGp0C5ssiKXiqWzVD5coHNUOpyhI7Nqj/HI23IP5J8lMcKTpfgwQwPZvhr15XyvLezygGZy
ijIo2wKjYUIzRbqCZFB+49shtctg3KeXe4BuYgWgRChPFYRKqf/2RufWx3dFX9wfJw7+ZnRkxmI2
T5gNFsO0ZdYbBPyzKOXWIBjD+bR+lhTSYD693ngIrf5XenH7B7mNdDvR6u+6/0vSe9uXVVNUr69v
+T83Hm193qw1UjU6T6V9KaQbzw4zOBU0+U0QYXSNzgy9LMPq6SFknMDQM2ps3GfFQT/jZbwQR3az
9NO6+q+31tv5Smvl8s2NB5VmbllcAxQyX1wEm8RN5G/QIl/JFaF0KsOl6SyVxdMIkHVxViP4a8sv
j78AnX1Tt3ffwG9f3XtgzyhgOWPwnNBgylo5tW7Rm8yAZa6RXIG+kN78XNrbkXYDfCN6vgiKVMIf
h0iWZAgapRCPy3ZWf+6d6QPdP9telk5tf6OyiZlPK5uNK/2NdrPUoCtUwZO2ARkrd3oYHJodNA1A
pld18rOD8ksXhdXyRuv+tdudq7eL1fPt+ieNTrbFloDEZXZ1FcwFU4QIBWP+KKEwlC/YBWIPgsEn
XlCb86XNwqV8vb/aKlTSQoZPRhP0gvJGEQFK07z+MHjINTAu90ET8jPvy7uO/FT64XWp56t/Sc8B
f/l66X/S98D5cJFagwpcQSxBShsUinSZyhEpL5CeY1EYPOT+3dQ+aGrw6Gv7dh9968CRPcfen9xz
Uv6+DsDGHGRQE1RQANPyiksxEM3EOD712T+uPlZg4F6hw1/SvfLHg/oPhg797Peyaj8wOXwKmdEQ
AZoJaIOKC8bAeISj4xBDi5WFjfW/L90tXF95Uv8y9xBIXY+tXQDzwaRPVIZMMF4aVxSFIZjTZjAd
7A555/7z21dU/weN6Gt4CmVuZHN0cmVhbQ1lbmRvYmoNMjAgMCBvYmoNPDwgDS9UeXBlIC9Gb250
RGVzY3JpcHRvciANL0FzY2VudCAwIA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50IDAgDS9GbGFncyA0
IA0vRm9udEJCb3ggWyAtMTUyIC0yNTEgMTIzMSA5MTIgXSANL0ZvbnROYW1lIC9FRUZHRk8rR2Fy
YW1vbmQuQm9sZGkwNzkgDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgMCANL0NoYXJTZXQgKC9HNzIv
RzgxL0c3My9HNDAvRzgyL0c3NC9HOTIvRzUxL0c3Ni9HODUvRzQ0L0czL0c4Ni9HNzAvRzU0L0c3
OS9HNzEpDS9Gb250RmlsZTMgMjEgMCBSIA0+PiANZW5kb2JqDTIxIDAgb2JqDTw8IC9GaWx0ZXIg
L0ZsYXRlRGVjb2RlIC9MZW5ndGggNDcwMCAvU3VidHlwZSAvVHlwZTFDID4+IA1zdHJlYW0NCkiJ
ZJRtUBN3HscTIbD1+Yk2ayi5a29O69OggGjb6dSKRtRqRaggWlQgECCEABLYkGSzu9nsbnY3T5uH
DZEoQUAgNBEEEfSEY9DxoY5t7Xijd3Xam7ne3M1NO53ecrd27uKL3pt79f89vPn8PvOdv1SSukgi
lUrBvXv3qfYd2aQ603xGq2us2vqBrqFKk52/6+Xyg4XNixa2pCysTRW3Lk35YWnqwtalr4r3XgQy
X/lDZvohWdYFyX7E+h+H43/F0nShfaXgWCGMrGIz1xxfLVkrlaamL162cs2rYKbyjd+s37glO+fg
sSpV/nbVzm2q/BxVbrZq53ZVfq5q13ZVXnKyQ7UzT5Wbq8pR7dyhys9W5eWq8nep8rd9qGvUtXY0
VVdsqfiFteIl6y/N/x8gkaxK2bA5Z8c+1f7CA4eOHC0q+fikROqRUlK3lJX6pJw0ILVLSSktdUr9
UkLqkLqkXikjWZ0UI1kkkUmHF7lTJlPvy7C0F+kvXilcsmbJj0svLltYPrSif+X86ozlL8aWL7y+
0JYpW5txhRgiLhE30dv2h3SUusv8wy1scgqvs8ISRjhAy8eoefwr1GNytKNte8WzcvgMiRM2EgOT
L2VxQCwYpCJEX5bxc3s/fBmKgZ1sG61nAdzAODXKI2whW0C/Te0mD1AY1FpYKaYVi+/IT4trwgRP
BWhQWEJ9Q99033LGPDzHe7tC4Qt+vm968jnAp82lQYfNp2Bda4HxFGpADHgnbsUN1kZLFVyJalEI
a5UXpDE+poeNcbfpBB4m/BYO8sBsOZtHb6DeI0oIm8EOE4T+7bb9xtL3xXo52uSEeKSn8xkmKOm/
Us88D0PT3PWeayN3xufvzv0RuBimmaCSI30OnsHaMZPNatTKfyseLRLTZGSFxtGsUK+nOTFHKcoY
MZMV85h3yfWEuAQHzqSJK/DoI57pYxJu8EvPzcAgHwoHotyg0+eOeAcCg3Jh1cKyUSH1hpCXEFJj
wkqGpV10ACTdiMvEAjYry8LKGk+tU8MCFhPNQsrBp7LlIvG1OyP6Oc/2uoY4cNo34o8GI+fDA4FE
Qlgsfyq0h2duCK/1PmTc4FVBfnEmJqTxEzLazfhC61oDZ71HnIDJ4mBRZd+3wgg8QlygOBocpe6x
33pu0INMkCFMdiuBEWabCYW0sAZRo2pEi+pRaweshxsQLdZqh4BKUdaQaziyTeySl4uKQrHcVEVh
JEahYML6qW2QcCczMESQbTiEmwnEbrWZAArBHTZFG2Em7QxOoozFCaAVTu49pbiHrSGPE3tx0PZJ
I2VSONKXC0cXajNTH2VEnwgW40+MbDTtKpkkdN9MEgbo59QdfBS9Y5o4N6Dr10bOeku4Y0QZ9Em1
uHjf5rf2bNrz6xoxlQHUZI2r3lfv1fEtEbbb0+ePAUSYdwQVQcrv4Og5aiY0NfxgdOr+4Hc99zy/
Q8eRMWhAH6rtPuUrocupaqzJjFhtCI4B4tYX9cYq+DRlxc0YBOp2nRZfKxa3YecQLaIGhWMtBEQk
zwRJGDNbIchuJhHGQFYzRa5i10FmN7OTfAd/FwEIs4HSKZxhlmcDjNPlc/GfReTX/WOheCQY5s67
wqyb8bA+V8TXHxz9izAs/7vwSHZd2Bh9xq9jw0QX6sd8Rk7vKuU0HsgDJD0ZM1N/zkwVMlpsGrgi
y1Rg+rhTTZpsZgSGCfleJ8zIvkHmO4az6m6V9qnoQqoIKq0tq9WchspNFe6z0apo5WfVgkQTN40b
pvRTTTFdRHvpNH+WUQNMJXrSUNx2sO7Dio9aNQ3aqqbmc5Utpc2ljWWGchiwnDiMFyhOlXj4j5Ti
opiOa/diHEjRpNu/zhlgXaHJ6HOQH/dddkcCCfl3tOd9d4XTBHprQrqw4XxbtOMyPGQewUfpODXm
mQpNhyZ6E59eifUmglfDU9i1hnHDpUMxUTIBiJLxgoQ6VhNrm0TnsDnnbHgm/uPDP3//+IfHwsq4
sIEZJq/h88gIOtk5a3ip5Ff/3id0Z2A+j51V8IgXcaOVqoNFO04AJ3ZsbH1Dsf9wsL9IeayvKt46
DcWQq+wt9qZn3B/vuto3HZ+Nz9y4NX/j9tTDxJOBJ/3PQl/TQjr1uH24FoipfTVmDaxub2o26Nt0
1nq6iTrnhbqhMDJITQCXkR4Tn2XyGzx65hB5sEl1XFVStrshWy3KHDnxA4nCufondIIacfb7Is6+
YOyCz3WeH4gC/T2REMe95P5qoedfwYzRi/FQLBDzTnJzHmA27TF5p3n6hL9XfuHB6D9HhZSuL5FB
kAibvMkPtaXD5TUru6Z4NsxEaDAy5uHvKuPeny72sEHWSYMU63a4FEbKSuBZNiMO2QxQmf5dsKME
0XaU1b957rBVZzxjKAYJC4USNrNaTsAkQtgJ2G6ydbQXy1ED1mZtstSBcI21AW1KBtxqR/W75Zge
0cINPrTPNknyZJDkKMDiwCgii8JsqNWiQ+vtDcQWS0HnKQNgOWfCEYUNdbBWpcvPcgwTmuAGaB62
mbB29HjjyY5KBIArK4hyRf5hfrhSWTRZN2u7jz/wfdH7dFJY972QJmT/LannTz+/lcETQcpL91BR
54Cv3zsYGol4u50hxvOFoB4V1nATgTnsWvOQfrC6q5RupLQ2rRXQwk3GlvZkfOuaazUl+hPGCrWY
Yt91qajv6FTdI+yl9zeFyMJQRmK270qk+/czs/+luNxj27rKAI6AmguM/YXhuqnqClSEEBVDHevo
1q7rEO26jkLXNm3IY2lcZ2njV+JXbN9rX18/7r2+D1/fh68fsR07fiSOYydOmpeTNF1K1q5QKGMP
JARiCGkgBGiTXHY7iRudP4/06Tvf953f+Z3FzepWZTlXj6+J82yRuoe3wnVkFilDGVfFnLdIFsnE
GahBgNajfe4r8hdo0ICfZg6yespCuikAxwYjpzp+pAr5MBQLeRV2hnSYjhpijbFhyZJ2ZG05Tx7d
dIIbeJ0aZ2vRaa4kVoT6+GIx60hAAvzc6Re6TxoB40vH4ec7OgeiwrD2Kj80bi6aJu1T8BwAz6KN
hb1Ui10Uqpnb+c1CSznEo49uqqU6U8dqWBUuWzO2rIUfpvrwbucVXddV3SXzmbaTAJN4jirSQC5J
UqwWj/GR+C5qH1/cZtTp7QRT4pqipinkuSgrsDEFTrE8WPiVVFe6xlAcLTEiyEg0f6t94n77ApP1
4WMRK605q8JCFO3XsuloghZjaSElSVm8Se+wU+/P/WH14dqD1nZrqV4Gt+vrxYXkYmKF3yDXiTl/
yVNypRz0KGMhrH4HanKOGmwGm8lrVsjpirmTAMohWf8MOh3I+oVADGZcyoYdtbsdLqfVZfIMW8/d
OHxN/jyIGLJE+6sMSwh4nNBE/XQACwecysuOh8KBIKIJBAOEnwRQ1XGVj0AiARJAVEQQwaEO5xUi
hAdwv8Y7gI4E4Svyd8E3DhiesZ4N6nmfRnLMwjshEeNxDsNduKINOBpCAjDwkiqI6+mfsBcZ8DIx
gBsIAHNfwA7tFnOzjctfVz+bvzLpqDor2Iw4L5ZT+Vx6IvHhSvsH716auzEPN6DVyGpyLbEwuVJd
u/vrBxvv14D3Zv6W/i95k6hhZUwK5wIV7wwElqwT9rT9Lt+KNxMlNk+nyQTBBxkf4w2ZPQO+a5AF
gjwQFPCRGIEwLhHQZ68LJprsDvRBA+4uQ3dfb39v59AvRo/qToz9lOwjDKSHtpEGVhc/fb3LPOwA
IBiBg3AYImHez3uTgSIGYFGO4Dpq2Cpxh+SJAtmkRUV+YlT7afzjkdVfLneKPxt5ER4YvTaoH7p2
9UaPrXfkrP3YGOA89hz6447Dx7n0y9pX0n0V07yjEp4WavGZ/NRMsTb5wVT7icbuqH7j0UH1CrE0
vtJcbtR3Jv/U+CT+jqvhnh3KXCaDhJMw4m+geqtON6C7ccn2StCBDEKdQNiKOygPZWYdvIfzJLwZ
NItkwxOkElA+99lV9cfiX4oPFpdKpTJfYhNkAlMWKnkSUHKMs7IAO/w6c75DfpLeI3/uuGekR9tr
Hh509wWs9Khki1srziUYgJbWQ7c70gWSrmp3r4X/0Xv7vlhXK6iems5XJ2rxWbJJTMFpa3qEMfsU
C4KtY1aXzeo0w2bIErBSw7hFcpUBVwmbiTeVxB4v7pM71dn77a8kMnQixgkagReyQpWJg3Q0muQm
+Gwsw6RZMVYUGul1MLX6ZvsIn2FydEGD8UjMxbliw2wXk30TfEi/ndwpLiRala0F4Deq0SODB3rk
b8oHH38fRE0BS9Ce8U+jN4PpcALjMMdF0IVBEZRCcHfEQZ+hnyJlQMnuOjFMDGN23EvtYu9xKt9S
Z/hcbJJeoyscJ2RTmfr47X+2Z5W35rftvnfbrmRzT2aLa5b3jkk21kR5cIiCo3SSFimBpmmWEW7T
d6R7+fuZ9fxcvkKCBMtFhI4XZU+n/EPjEb8paFdmKwSGnPL3Hv+8S/4OOooYCHvUr0HYZLDQIYVL
2DwGuDEvFtyPoxgS8B1nwH7qNeplUk+Bevw8diIEnFTFV/Y8+cHOtjrDjkdT0XnFe1lWYjguKgqi
OJVarfwVnPxd7ZPcvcQCXyMrGooLCT4RjpviA8lECxSEXdxxFU5qaRelsiCyQJSlWE4bj4oxkStK
M4X5+i0GVIw2DO9CW4MHQy509Perb9U2sw8m7kob1Nv4urs+DDRuZAZ1e6l++9F++Wvyl+Q/gqEx
HKZQNpgKlbFlBGSQiC+E4AimeKD8WhI8h+/pVcn7fHuGVDRHs7G9UT4qRdOAWKDZea0gUlFJm6Z5
lonxQnyCn8nelha5arP9ZbDV1uY+DNYDa8ZCJ6XH+/3dYz2OTuMFPeoGnWdHT12WD/stCv3cr9Kw
JgqVPetuAFaKGN5P+ANen9uBjUWUduFWysh+iwIv4sfwgxgQjcQYfj/JKKAe3x2CyKf//t+IutKf
6qI7mQuootDGp3Qnuy+deuaFc0d0wMCzT48d6vj287nWee355aEt3w5yR3in8vfUYn65slxZqc3P
1RrVRrlR2J6+NdFKrkvb7D2qfQD/x0DrqBL/s0Pyv9T2I74upR49lI41xKypsTxUcM2gTaqFryZv
VpcqC63ZB5OLlYfV/yy2nxD+bN0EbGs9xTPUZbwb6jP1G3X91y/Y9Ybjr8vAbsryp9tbapFNRhNs
g21IDeV3mNuqfrTdPjrbVklv0TwmBAQ45oiZecBHBmPSXqGxwW4kWxVNa7JZqUylE5IoCA9pEFec
XamYH0OCKGoJOoMQhqJGd+/S8lQ1neajhXSjWE5NcRVqFi/BaRuQtkTNXgNyfcxkHDVZDPAQZVKu
/GgRluCYjwQCKk/Q5XU4jEM2xRRDZhC6rJeBV+XTuDPiYiDh/yWXz0/TcBjGDyr26oGE0WRLTDQm
hqN6kng0EoiJoiQQQKJbJgMcDsa60bVrv+23W3+uW7uuhZFtOKab/M40C0RR9CCJZ4Px5NGzVevB
qv/B+z5P3uf9PESe1qAOlmE9XYcWKwMJZEi3jaYYiiKQng7nZm44PZaegB6sA3KB9HUo5oWc2whl
Mato/3YP2wP2VmdZNHnVRQ1FyaioQho3tPsq4TFmjDkrUUiWiBpZIlfYKr+b3tU317arlbrWyJYy
S4wJjFhxylqU/YV+Cxkw/RquzGoREytjJaICa8yG2MjVrL2VndVG9emzenO1aq0XW0sto6W2BOQD
95p9Sb1IreNPMASjA8SgN3mLnmQpBEAAWG8MxDlXcvfHEgLMQYMtJd9Gd2ZXw+WgPiaMcuPJifB0
dP5RMkRH5Ig1jxTDTeyA+Bw9jDax/al6UPPrD+AoNhy+OtTXO4Tcudbz2DmJLvrFbL9vVpyUgzrF
z+WDFiNCiXNTXa7l973WsbYnWf9Jzvj5qrPClwRTUDk3i4T3dJvbFJD9Dvu8KgKJFaEHD1EYpBFI
UhyNwriLaahre4ZESYZiGAZxD5rqti4oPflLhV6P6ZzOKu2jr/YZz3f73LsvWklRJZXPIaIs6WZ3
Mu/WCzElzbvDTatdvHFKkAVZ7nbjMZ8tICsGL6i+T+CAK3Nb0qHq2RBrginCKINDgDAQsLQXd9E8
zoWpCFhg8RRF03BhZuJ23xXH6wx2OW9+n3XGHfPe3bHxkYAnlogRCzRChCaZAApjgvzQN6dEi3gZ
mJwpLRnPa83tBmI2K/kCWl+Lh9Z88aJO66imZws53zf7xNFxoz3y42IXbl9O2KfiH+kGu0xngUzK
CQUBpKySPqnAFwXzr5y/2p1/AAYdmfkKZW5kc3RyZWFtDWVuZG9iag0yMiAwIG9iag08PCANL1R5
cGUgL0VuY29kaW5nIA0vRGlmZmVyZW5jZXMgWyAxIC9HNDQgL0c1NSAvRzIxIC9HMTkgL0cyMCAv
RzE1IC9HMyAvRzU0IC9HODggL0c2OSAvRzgwIC9HNzYgL0c4NiANL0c4MiAvRzgxIC9HNzMgL0cz
NiAvRzg3IC9HODUgL0c2OCAvRzcwIC9HNzUgL0c3MiAvRzM4IC9HODkgL0c3NCANL0c3OSAvRzcx
IC9HOTIgL0c4MyAvRzYwIC9HOTAgL0cyOSAvRzkxIC9HNTEgL0c0MCAvRzkzIC9HMTcgL0c1MyAN
L0c0OCAvRzUwIC9HNTYgL0c0MyAvRzQ5IC9HNzggL0cxMCAvRzQxIF0gDT4+IA1lbmRvYmoNMjMg
MCBvYmoNPDwgDS9UeXBlIC9FbmNvZGluZyANL0RpZmZlcmVuY2VzIFsgMSAvRzU0IC9HODggL0c2
OSAvRzgwIC9HNzYgL0c4NiAvRzgyIC9HODEgL0czIC9HODMgL0c3OSAvRzkyIC9HODcgDS9HNzUg
L0c3MiAvRzczIC9HNjggL0c4NSAvRzc0IC9HMTUgL0c3MSAvRzExIC9HMTIgL0cxNyBdIA0+PiAN
ZW5kb2JqDTI0IDAgb2JqDTw8IA0vVHlwZSAvRW5jb2RpbmcgDS9EaWZmZXJlbmNlcyBbIDEgL0c1
MCAvRzgxIC9HNzkgL0c5MiAvRzMgL0c4MiAvRzg1IC9HNzYgL0c3NCAvRzY4IC9HODAgL0c4NyAv
RzcyIA0vRzg2IC9HNzUgL0c4OCAvRzcxIC9HNjkgL0cxNyAvRzM4IC9HNzAgL0c4MyAvRzE1IC9H
NzMgL0c5MCAvRzE4IA0vRzg5IC9HMzYgL0c0MiAvRzIyIC9HMTkgL0cyMSAvRzIwIC9HNDAgL0c1
NCAvRzUxIC9HNDQgL0c1OCAvRzc4IA0vRzU1IC9HMTYgL0c4NCAvRzUzIC9HNDkgL0c0NyAvRzYw
IC9HNTYgL0czOSAvRzI5IC9HNDggL0czNSAvRzkxIA0vRzExIC9HMTIgL0c3NyAvRzQzIC9HNTcg
L0c0MSAvRzM3IC9HMjggL0cyNyAvRzI2IC9HMjQgL0c1OSAvRzI1IA0vRzIzIC9HMTAgL0c0NSAv
RzMwIF0gDT4+IA1lbmRvYmoNMjUgMCBvYmoNPDwgDS9UeXBlIC9FbmNvZGluZyANL0RpZmZlcmVu
Y2VzIFsgMSAvRzQgXSANPj4gDWVuZG9iag0yNiAwIG9iag08PCANL1R5cGUgL0VuY29kaW5nIA0v
RGlmZmVyZW5jZXMgWyAxIC9HNTEgL0c4NSAvRzgyIC9HNzAgL0c3MiAvRzcxIC9HNzYgL0c4MSAv
Rzc0IC9HODYgL0czIC9HNzMgL0c1NCANL0c0NCAvRzQwIC9HNTggL0c3OSAvRzY5IC9HNjggL0c4
NyAvRzg5IC9HMTUgL0c4MyAvRzc1IC9HOTAgL0cyOSANL0c1MCAvRzUzIF0gDT4+IA1lbmRvYmoN
MjcgMCBvYmoNPDwgDS9UeXBlIC9FbmNvZGluZyANL0RpZmZlcmVuY2VzIFsgMSAvRzgyIC9HODEg
L0c3OSAvRzkyIC9HMyAvRzcyIC9HNTEgL0c4NSAvRzcwIC9HNzEgL0c3NiAvRzc0IC9HODYgDS9H
NzMgL0c1NCAvRzQ0IC9HNDAgXSANPj4gDWVuZG9iag0yOCAwIG9iag08PCANL1MgL0QgDT4+IA1l
bmRvYmoNMjkgMCBvYmoNPDwgDS9OdW1zIFsgMCAyOCAwIFIgXSANPj4gDWVuZG9iag0zMCAwIG9i
ag08PCANL1R5cGUgL1BhZ2VzIA0vS2lkcyBbIDQ0IDAgUiAxIDAgUiBdIA0vQ291bnQgMiANPj4g
DWVuZG9iag0zMSAwIG9iag08PCANL0R0IChEOjIwMDAxMTI5MTU0NjM4KQ0vSlRNIChEaXN0aWxs
ZXIpDT4+IA1lbmRvYmoNMzIgMCBvYmoNL1RoaXMgDWVuZG9iag0zMyAwIG9iag08PCANL0NQIChE
aXN0aWxsZXIpDS9GaSAzMiAwIFIgDT4+IA1lbmRvYmoNMzQgMCBvYmoNPDwgDS9QbyB0cnVlIA0v
UiBbIDYwMCA2MDAgXSANPj4gDWVuZG9iag0zNSAwIG9iag08PCANL0pURiAwIA0vTUIgWyAwIDAg
NjEyIDc5MiBdIA0vUiAzNCAwIFIgDS9XIFsgMCAxIF0gDT4+IA1lbmRvYmoNMzYgMCBvYmoNPDwg
DS9GaSBbIDMzIDAgUiBdIA0vUCBbIDM1IDAgUiBdIA0+PiANZW5kb2JqDTM3IDAgb2JqDTw8IA0v
RG0gWyA2MTIgNzkyIDYxMiA3OTIgXSANPj4gDWVuZG9iag0zOCAwIG9iag08PCANL01lIDM3IDAg
UiANPj4gDWVuZG9iag0zOSAwIG9iag08PCANL0QgWyAzNiAwIFIgXSANL01TIDM4IDAgUiANL1R5
cGUgL0pvYlRpY2tldENvbnRlbnRzIA0+PiANZW5kb2JqDTQwIDAgb2JqDTw8IA0vQSBbIDMxIDAg
UiBdIA0vQ24gWyAzOSAwIFIgXSANL1YgMS4xMDAwMSANPj4gDWVuZG9iag00MSAwIG9iag08PCAN
L0NyZWF0aW9uRGF0ZSAoRDoyMDAwMTEyOTE1NDYzOCkNL1Byb2R1Y2VyIChBY3JvYmF0IERpc3Rp
bGxlciA0LjA1IGZvciBXaW5kb3dzKQ0vQ3JlYXRvciAoV2luZG93cyBOVCA0LjApDS9UaXRsZSAo
SDpcXFRQXFxJVDAxXFwuLi5cXElUMjAxIFNDLndwICAgICAgIFtQRlAjMTEwMjQ3NTQ1Nl0pDS9N
b2REYXRlIChEOjIwMDAxMTI5MTU0NjM4LTA4JzAwJykNPj4gDWVuZG9iag14cmVmDTAgNDIgDTAw
MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAxNjE1NCAwMDAwMCBuDQowMDAwMDE2MzA1IDAwMDAwIG4N
CjAwMDAwMTY1MDcgMDAwMDAgbg0KMDAwMDAyMzM1NCAwMDAwMCBuDQowMDAwMDIzNzE2IDAwMDAw
IG4NCjAwMDAwMjM5ODQgMDAwMDAgbg0KMDAwMDAyNDQzMSAwMDAwMCBuDQowMDAwMDI0NjE1IDAw
MDAwIG4NCjAwMDAwMjQ5MDIgMDAwMDAgbg0KMDAwMDAyNTE0NCAwMDAwMCBuDQowMDAwMDI1NTU2
IDAwMDAwIG4NCjAwMDAwMzg0NDcgMDAwMDAgbg0KMDAwMDAzODc2MyAwMDAwMCBuDQowMDAwMDQx
NTczIDAwMDAwIG4NCjAwMDAwNDIwNzAgMDAwMDAgbg0KMDAwMDA2MDU2OCAwMDAwMCBuDQowMDAw
MDYwNzk4IDAwMDAwIG4NCjAwMDAwNjExMTkgMDAwMDAgbg0KMDAwMDA2MTQ1OCAwMDAwMCBuDQow
MDAwMDY5MjMxIDAwMDAwIG4NCjAwMDAwNjk1MjAgMDAwMDAgbg0KMDAwMDA3NDMxMiAwMDAwMCBu
DQowMDAwMDc0NjEwIDAwMDAwIG4NCjAwMDAwNzQ3OTEgMDAwMDAgbg0KMDAwMDA3NTIwMSAwMDAw
MCBuDQowMDAwMDc1MjY2IDAwMDAwIG4NCjAwMDAwNzU0NjggMDAwMDAgbg0KMDAwMDA3NTYxNCAw
MDAwMCBuDQowMDAwMDc1NjQ1IDAwMDAwIG4NCjAwMDAwNzU2ODkgMDAwMDAgbg0KMDAwMDA3NTc2
MSAwMDAwMCBuDQowMDAwMDc1ODI1IDAwMDAwIG4NCjAwMDAwNzU4NDggMDAwMDAgbg0KMDAwMDA3
NTkwMCAwMDAwMCBuDQowMDAwMDc1OTUwIDAwMDAwIG4NCjAwMDAwNzYwMjYgMDAwMDAgbg0KMDAw
MDA3NjA4MSAwMDAwMCBuDQowMDAwMDc2MTMwIDAwMDAwIG4NCjAwMDAwNzYxNjYgMDAwMDAgbg0K
MDAwMDA3NjI0MyAwMDAwMCBuDQowMDAwMDc2MzEwIDAwMDAwIG4NCnRyYWlsZXINPDwNL1NpemUg
NDINL0lEWzxiZDFmNzYyODY4ZTAwYTQ3NTljN2FkY2VjODE1ZjYzZT48YmQxZjc2Mjg2OGUwMGE0
NzU5YzdhZGNlYzgxNWY2M2U+XQ0+Pg1zdGFydHhyZWYNMTczDSUlRU9GDQ==

--0__=1wj55wbMuTLaPmr8Vlgwmlg8x6MSQcPhFaLr2uYDP8KJkX3qiio0mrEY--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec  4 17:00:49 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15603
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Dec 2000 17:00:49 -0500 (EST)
Received: from standards (47.234.32.16:2518) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF290@standards.nortelnetworks.com>; Mon, 4 Dec 2000 16:41:53 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 158811 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Dec 2000 16:41:52 -0500
Received: from zrchh190 (47.158.65.22:44907) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBBF271@standards.nortelnetworks.com>; Mon, 4 Dec 2000 16:31:51
          -0500
Received: from smtprch1.nortel.com (actually erchg0j) by zrchh190; Mon, 4 Dec
          2000 15:49:07 -0600
Received: from zrchb213.us.nortel.com (actually zrchb213) by
          smtprch1.nortel.com; Mon, 4 Dec 2000 15:34:59 -0600
Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <YCBXWK3D>; Mon, 4 Dec 2000 15:34:47 -0600
X-Mailer: Internet Mail Service (5.5.2652.35)
X-Orig: <taylor@nortelnetworks.com>
Message-ID:  <28560036253BD41191A10000F8BCBD11030621A6@zcard00g.ca.nortel.com>
Date:         Mon, 4 Dec 2000 15:34:27 -0600
Reply-To: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Subject:      Draft Megaco Agenda
X-To:         agenda@ietf.org
X-cc:         ITU-SG16@MAILBAG.INTEL.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Megaco is meeting on Wednesday morning from 9:00 to 11:30.  Here is the
proposed Megaco agenda.  The primary intention of the meeting is to get a
quick sense of the readiness of each I-D for the next step in the process.
Given that we are running out of charter, we will not be adding WG work
items.  The possible dispositions are therefore limited to:
 (a) No interest
 (b) More work needed
 (c) Ready for list last call
 (d) Forward to IESG as Informational
 (e) Forward to IESG as potential Standards Track

For packages, presentations should show the following:
 (1) Package summary: name, one-line description, list of properties,
events, signals, and statistics defined.
 (2) Recent updates and any open issues.
If you're not presenting your package, let me know ASAP and I will do it.


Draft Agenda

1. Agenda Bashing (2 minutes)

2. ITU-T SG 16 Status
                  Tom Taylor (5 minutes)

3. Completion of charter items
   (a) MIB (draft-ietf-megaco-mib-01.txt)
                  Matt Holdrege (20 minutes)
   (b) NAS package (draft-ietf-megaco-naspkg-02.txt)
                  Tom Taylor (3 minutes)

4. Well-aged package proposals
   (a) draft-boyle-megaco-tonepkgs-01.txt
   (b) draft-boyle-megaco-alerting-00.txt
                  Kevin Boyle (5 minutes)
   (c) draft-cornel-megaco-enhancedd-00.txt
                  Sarah Cornel (3 minutes)
   (d) draft-scoggins-megaco-pktnetpkg-00.txt
                  Sophia Scoggins (3 minutes)
   Contingency: 10 minutes

5. ISDN
   -- draft-bouwen-megaco-isdn-bcp-00.txt
   -- draft-bouwen-megaco-isdn-data-00.txt
   -- draft-bouwen-megaco-isdn-pack-00.txt
                  Jan Bouwen (15 minutes)

6. Other Proposals
    (a) draft-rosen-megaco-namepatterns-00.txt
                  Brian Rosen (10 minutes)
    (b) draft-cutler-megaco-recvpkg-01.txt
                  Wayne Cutler (10 minutes)
    (c) draft-levy-megaco-mgdiscovery-01.txt
                  Thomas Levy (10 minutes)
    Contingency: 15 minutes

7. Issues From The List
                  Tom Taylor (15 minutes)

8. Interop
   Reference draft-rosen-megaco-test-profile-00.txt
   and draft-rosen-megaco-interop-1-report-00.txt
                  Brian Rosen (10 minutes)

Hope I've covered everything that's current.

Tom Taylor
+1 613 736 0961
taylor@nortelnetworks.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec  4 18:09:11 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11288
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Dec 2000 18:09:10 -0500 (EST)
Received: from standards (47.234.32.16:2784) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF2BA@standards.nortelnetworks.com>; Mon, 4 Dec 2000 17:50:00 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 158901 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Dec 2000 17:50:00 -0500
Received: from zrchh190 (47.158.65.22:53475) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBBF2B5@standards.nortelnetworks.com>; Mon, 4 Dec 2000 17:39:59
          -0500
Received: from zrtps06s.us.nortel.com by zrchh190; Mon, 4 Dec 2000 16:58:00
          -0600
Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Mon, 4 Dec
          2000 15:35:56 -0500
Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <Y22KF0Q2>; Mon, 4 Dec 2000 15:31:52 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
X-Orig: <taylor@americasm01.nt.com>
X-Orig: <taylor@nortelnetworks.com>
Message-ID:  <28560036253BD41191A10000F8BCBD1103061FF9@zcard00g.ca.nortel.com>
Date:         Mon, 4 Dec 2000 15:31:47 -0500
Reply-To: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Subject:      Re: Registration Of Megaco/H.248 Packages
X-To:         iana <iana@iana.org>
X-cc:         ITU-SG16@MAILBAG.INTEL.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

In the Megaco/H.248 package registry at
http://www.isi.edu/in-notes/iana/assignments/megaco-h248
<http://www.isi.edu/in-notes/iana/assignments/megaco-h248> , the packages
marked "IP 11/00" are now "Final".

I will have a few new packages for you shortly.

Thanks a lot.

Tom Taylor
taylor@nortelnetworks.com <mailto:taylor@nortelnetworks.com>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec  4 18:20:50 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14294
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Dec 2000 18:20:50 -0500 (EST)
Received: from standards (47.234.32.16:2784) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF2DE@standards.nortelnetworks.com>; Mon, 4 Dec 2000 18:01:55 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 158953 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Dec 2000 18:01:54 -0500
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBBF2DD@standards.nortelnetworks.com>; Mon, 4 Dec 2000 18:01:54
          -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id SAA19764; Mon, 4 Dec 2000 18:19:25 -0500 (EST)
Received: from stl-server-01.pit.comms.marconi.com
          (stl-server-01.pit.comms.marconi.com [169.144.36.27]) by
          mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA16897;
          Mon, 4 Dec 2000 18:19:25 -0500 (EST)
Received: by stl-server-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <YB6WRV5N>; Mon, 4 Dec 2000 18:19: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:  <4FBEA8857476D311A03300204840E1CF01A6EB12@whq-msgusr-02.pit.comms.marconi.com>
Date:         Mon, 4 Dec 2000 18:19:16 -0500
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: Draft Megaco Agenda
X-To:         "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Can we not have a re-chartering discussion?

Brian

> -----Original Message-----
> From: Taylor, Tom-PT [NORSE:B901:EXCH]
> [mailto:taylor@AMERICASM01.NT.COM]
> Sent: Monday, December 04, 2000 4:34 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Draft Megaco Agenda
>
>
> Megaco is meeting on Wednesday morning from 9:00 to 11:30.
> Here is the
> proposed Megaco agenda.  The primary intention of the meeting
> is to get a
> quick sense of the readiness of each I-D for the next step in
> the process.
> Given that we are running out of charter, we will not be
> adding WG work
> items.  The possible dispositions are therefore limited to:
>  (a) No interest
>  (b) More work needed
>  (c) Ready for list last call
>  (d) Forward to IESG as Informational
>  (e) Forward to IESG as potential Standards Track
>
> For packages, presentations should show the following:
>  (1) Package summary: name, one-line description, list of properties,
> events, signals, and statistics defined.
>  (2) Recent updates and any open issues.
> If you're not presenting your package, let me know ASAP and I
> will do it.
>
>
> Draft Agenda
>
> 1. Agenda Bashing (2 minutes)
>
> 2. ITU-T SG 16 Status
>                   Tom Taylor (5 minutes)
>
> 3. Completion of charter items
>    (a) MIB (draft-ietf-megaco-mib-01.txt)
>                   Matt Holdrege (20 minutes)
>    (b) NAS package (draft-ietf-megaco-naspkg-02.txt)
>                   Tom Taylor (3 minutes)
>
> 4. Well-aged package proposals
>    (a) draft-boyle-megaco-tonepkgs-01.txt
>    (b) draft-boyle-megaco-alerting-00.txt
>                   Kevin Boyle (5 minutes)
>    (c) draft-cornel-megaco-enhancedd-00.txt
>                   Sarah Cornel (3 minutes)
>    (d) draft-scoggins-megaco-pktnetpkg-00.txt
>                   Sophia Scoggins (3 minutes)
>    Contingency: 10 minutes
>
> 5. ISDN
>    -- draft-bouwen-megaco-isdn-bcp-00.txt
>    -- draft-bouwen-megaco-isdn-data-00.txt
>    -- draft-bouwen-megaco-isdn-pack-00.txt
>                   Jan Bouwen (15 minutes)
>
> 6. Other Proposals
>     (a) draft-rosen-megaco-namepatterns-00.txt
>                   Brian Rosen (10 minutes)
>     (b) draft-cutler-megaco-recvpkg-01.txt
>                   Wayne Cutler (10 minutes)
>     (c) draft-levy-megaco-mgdiscovery-01.txt
>                   Thomas Levy (10 minutes)
>     Contingency: 15 minutes
>
> 7. Issues From The List
>                   Tom Taylor (15 minutes)
>
> 8. Interop
>    Reference draft-rosen-megaco-test-profile-00.txt
>    and draft-rosen-megaco-interop-1-report-00.txt
>                   Brian Rosen (10 minutes)
>
> Hope I've covered everything that's current.
>
> Tom Taylor
> +1 613 736 0961
> taylor@nortelnetworks.com
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec  4 23:39:00 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA07894
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 4 Dec 2000 23:38:59 -0500 (EST)
Received: from standards (47.234.32.16:4625) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF36A@standards.nortelnetworks.com>; Mon, 4 Dec 2000 23:19:55 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 159135 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 4 Dec 2000 23:19:55 -0500
Received: from web5104.mail.yahoo.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBBF365@standards.nortelnetworks.com>; Mon, 4 Dec 2000 23:09:54
          -0500
Received: from [208.220.245.72] by web5104.mail.yahoo.com; Mon, 04 Dec 2000
          20:27:28 PST
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID:  <20001205042728.20208.qmail@web5104.mail.yahoo.com>
Date:         Mon, 4 Dec 2000 20:27:28 -0800
Reply-To: Richie Wu <wuyongji@YAHOO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Richie Wu <wuyongji@YAHOO.COM>
Subject:      Re: Modification of event and sig parameter ASN.1 syntax
X-To:         Troy Cauble <troy@bell-labs.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi Troy,

Thank you for your timely response. I think your
solution is convenient for the protocol
implementation. We are confused with the value
codecing issues. As per your idea, I think the only
situation that we need to retain OCTET STRING is we
want to transfer raw data, which is opaque to the
protocol. In this case we can use the codec method
suggested in B.3 and B.4 of the implementor's guide
version 7.

And I suggest that we add comments in the package
definition section in order to uniform how to codec
the data type defined in this section. The data need
to be converted from host byte order to net byte order
in case of integer, double and boolean while encoding,
vice versus for decoding; the char and string type can
be memory copy directly. And the elements of sub-list
or enumeration type is also a type of integer, double
or boolean, hence they can be codeced following the
above rules. Thus, we can eliminate a lot of
interoperability problems.

Best regards,

Richie Wu

--- Troy Cauble <troy@lucent.com> wrote:
>
>
> Yes, please!  I've brought up the OCTET STRING
> problem
> before, and "double wrapping" the values was
> discussed.
>
> But we didn't talk about the missing Relation
> information
> (>, <, !=, etc.) !
>
> If people like your first proposal, I'd suggest that
> PropertyParm be reused rather than creating new
> constructs
> just like it.  The second version is good too; that
> construct
> maps directly to the ABNF parmValue.
>
> Either of these proposals would help a great deal.
> Since
> we're discussing changing the ASN.1, I'd propose we
> go a
> step further and get rid of the OCTET STRING hole,
> as
> follows.
>
>
>       Value ::= CHOICE        -- or another name, depending
>       {                       -- on which model below is chosen
>
>               boolValue       BOOLEAN,
>               intValue        INTEGER,
>               stringValue     IA5String,
>               -- etc.  for all the property/parameter
>               -- Types in section 12.1.2 and 12.2
>       }
>
> -troy
>
> Richie Wu wrote:
> >
> > Hello everybody,
> >
> > I have some doubts about the definition of Event
> > Descriptor Parameters and Signal Descriptors in
> ASN.1.
> >
> > In ASN.1 we have defined the syntax for event
> > parameters and additional signal parameters which
> were
> > described in package definition as the following
> > format:
> >
> > Value ::= OCTET STRING
> >
> > EventParameter ::= SEQUENCE
> >    {
> >         eventParameterName              Name,
> >         value                           Value
> >    }
> >
> > SigParameter ::= SEQUENCE
> >    {
> >         sigParameterName                Name,
> >         value                           Value
> >    }
> >
> > The issue is that we lose some information in
> Value
> > filed, because it loses the parameter type
> > information. And the appropriate items in ABNF
> which
> > matches the value field of the definition is
> defined
> > like:
> >
> > parmValue            = (EQUAL alternativeValue/
> > INEQUAL VALUE)
> >    alternativeValue     = ( VALUE
> >                           / LSBRKT VALUE *(COMMA
> > VALUE) RSBRKT
> >                             ; sublist (i.e. A AND
> B
> > AND ...)
> >                           / LBRKT VALUE *(COMMA
> VALUE)
> > RBRKT
> >                             ; alternatives (i.e. A
> OR
> > B OR ...)
> >                           / LSBRKT VALUE COLON
> VALUE
> > RSBRKT )
> >                             ; range
> >    INEQUAL              = LWSP (">" / "<" / "#" )
> LWSP
> >
> >    LSBRKT               = LWSP "[" LWSP
> >    RSBRKT               = LWSP "]" LWSP
> >
> > On  the other hand, as per the section ?12.1.2
> > Properties?, we have defined the ASN.1 syntax of
> > property parameters in package which is showed
> below:
> >
> > PropertyParm ::= SEQUENCE
> >    {
> >         name            PkgdName,
> >         value           SEQUENCE OF OCTET STRING,
> >         extraInfo       CHOICE
> >                 {
> >                         relation        Relation,
> >                         range           BOOLEAN,
> >                         sublist         BOOLEAN
> >                 } OPTIONAL,
> >         ...
> > }
> >
> > which have the samilar description in section 12.
> >
> > So, can we modify the appropriate ASN.1 definition
> > like this:
> >
> > SigsEventsParm ::= SEQUENCE
> >    {
> >         name            Name,
> >         value           SEQUENCE OF OCTET STRING,
> >         extraInfo       CHOICE
> >                 {
> >                         relation        Relation,
> >                         range           BOOLEAN,
> >                         sublist         BOOLEAN
> >                 } OPTIONAL,
> >         ...
> > }
> >
> > EventParameter ::= SigsEventsParm
> > SigParameter     ::= SigsEventsParm
> >
> > Or we modify the Value definition while leave the
> > other as it is:
> > Value ::= SEQUENCE
> >    {
> >         value           SEQUENCE OF OCTET STRING,
> >         extraInfo       CHOICE
> >                 {
> >                         relation        Relation,
> >                         range           BOOLEAN,
> >                         sublist         BOOLEAN
> >                 } OPTIONAL,
> >         ...
> > }
> >
> > Best regards,
> >
> > Richie Wu
> >
> > =====
> > Huawei Technologies India Private Limited
> >
> > Unit 10, 2nd Floor, Innovator Block
> > International Tech Park, Whitefield Main Road
> > Bangalore 560 066, India
> > TEL: 0091-80-841 0061/0753/0755
> > FAX: 0091-80-841 0063
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Shopping - Thousands of Stores. Millions of
> Products.
> > http://shopping.yahoo.com/


=====
Huawei Technologies India Private Limited

Unit 10, 2nd Floor, Innovator Block
International Tech Park, Whitefield Main Road
Bangalore 560 066, India
TEL: 0091-80-841 0061/0753/0755
FAX: 0091-80-841 0063

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Dec  5 01:48:03 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20963
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Dec 2000 01:48:02 -0500 (EST)
Received: from standards (47.234.32.16:3209) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF400@standards.nortelnetworks.com>; Tue, 5 Dec 2000 1:26:40 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 159260 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Dec 2000 01:26:40 -0500
Received: from zmers013 (47.124.1.40:41820) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBBF3C3@standards.nortelnetworks.com>; Tue, 5 Dec 2000 1:16:38
          -0500
Received: from tlhuph12.elex.co.il (actually ertpg1e0.us.nortel.com) by
          zmers013; Tue, 5 Dec 2000 01:33:48 -0500
Received: from tmx100.elex.co.il (tmx100.elex.co.il [141.226.8.254]) by
          tlhuph12.elex.co.il (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id IAA02524
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 5 Dec 2000 08:34:17
          +0200 (IST)
Received: from tmofpc19 by tmx100.elex.co.il (8.8.8+Sun/SMI-SVR4) id IAA10914;
          Tue, 5 Dec 2000 08:34:17 +0200 (IST)
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_00E2_01C05E95.F192C640"
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:  <00e501c05e85$2e365d70$ee0be28d@elex.co.il>
Date:         Tue, 5 Dec 2000 08:32:46 +0200
Reply-To: "Sherman, Nava [LOD:Telrad:SMTPPART]" <nava.sherman@TELRAD.CO.IL>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Sherman, Nava [LOD:Telrad:SMTPPART]" <nava.sherman@TELRAD.CO.IL>
Subject:      eventbuffersescriptor
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_00E2_01C05E95.F192C640
Content-Type: text/plain;
        charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

Hello!
as I understood the MEGACO/H248 events mechananism (reading the document =
someone wrote in this mail group), The  eventbufferdescriptor is used in =
H248 protocol, when the eventbuffercontrol parameter =3D lockstep in =
order
to decide which events are saved in the event buffer and which are not. =
(am I wrong?) when I look on the
commands and descriptor passed between the MGC and MG I see that the =
eventbufferdescriptor is only passed
from the MG to the MGC on responses (as response to audit?) but I didn't =
see how does the MGC sends this
parameter to the MG. (what I concluded from this that the MG copies the =
event descriptor tp the event buffer descriptor
when the event buffer contro =3D lock step. am I totally wrong.
I am sorry if my question is too naive, I'm new on this protocol.
Nava.=20

------=_NextPart_000_00E2_01C05E95.F192C640
Content-Type: text/html;
        charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1255" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hello!</FONT></DIV>
<DIV><FONT face=3D"Arial (Hebrew)" size=3D2>as I understood the =
MEGACO/H248 events=20
mechananism (reading the document someone wrote in this mail group), The =
=20
eventbufferdescriptor is used in H248 protocol, when the =
eventbuffercontrol=20
parameter =3D lockstep in order</FONT></DIV>
<DIV><FONT face=3D"Arial (Hebrew)" size=3D2>to decide which events are =
saved in the=20
event buffer and which are not. (am I wrong?) when I look on =
the</FONT></DIV>
<DIV><FONT face=3D"Arial (Hebrew)" size=3D2>commands and descriptor =
passed between=20
the MGC and MG I see that the eventbufferdescriptor is only =
passed</FONT></DIV>
<DIV><FONT face=3D"Arial (Hebrew)" size=3D2>from the MG to the MGC on =
responses (as=20
response to audit?) but I didn't see how does the MGC sends =
this</FONT></DIV>
<DIV><FONT face=3D"Arial (Hebrew)" size=3D2>parameter to the MG. (what I =
concluded=20
from this that the MG copies the event descriptor tp the event buffer=20
descriptor</FONT></DIV>
<DIV><FONT face=3D"Arial (Hebrew)" size=3D2>when the event buffer contro =
=3D lock=20
step. am I totally wrong.</FONT></DIV>
<DIV><FONT face=3D"Arial (Hebrew)" size=3D2>I am sorry if my question is =
too naive,=20
I'm new on this protocol.</FONT></DIV>
<DIV><FONT face=3D"Arial (Hebrew)" =
size=3D2>Nava.</FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_00E2_01C05E95.F192C640--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Dec  5 03:14:07 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24582
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Dec 2000 03:14:07 -0500 (EST)
Received: from standards (47.234.32.16:4329) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF457@standards.nortelnetworks.com>; Tue, 5 Dec 2000 2:52:38 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 159445 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Dec 2000 02:52:38 -0500
Received: from hindon.hss.co.in (202.54.26.202:34095) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBF456@standards.nortelnetworks.com>; Tue, 5 Dec 2000 2:52:36
          -0500
Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in
          (8.10.0/8.10.0) with SMTP id eB58ArF24894; Tue, 5 Dec 2000 13:40:54
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          652569AC.002BC05C ; Tue, 5 Dec 2000 13:27:52 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: multipart/mixed;
              Boundary="0__=wulMxxEl3b7KHyxllQnoLi7GNW0M0pZSbOnZ4YIkxJsuKmxp4fuv5nPT"
Content-Disposition: inline
Message-ID:  <652569AC.002BBF72.00@sandesh.hss.hns.com>
Date:         Tue, 5 Dec 2000 13:33:48 +0530
Reply-To: chassija@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chanchal Hassija <chassija@HSS.HNS.COM>
Subject:      Re: eventbuffersescriptor
X-To:         "Sherman, Nava [LOD:Telrad:SMTPPART]" <nava.sherman@TELRAD.CO.IL>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

--0__=wulMxxEl3b7KHyxllQnoLi7GNW0M0pZSbOnZ4YIkxJsuKmxp4fuv5nPT
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline



Hi,

It got added in the Add/Modify/Move commands in modifications mentioned in the
Implementor's guide.

Njoy
Chan...





"Sherman, Nava [LOD:Telrad:SMTPPART]" <nava.sherman@TELRAD.CO.IL> on 12/05/2000
12:02:46 PM

Please respond to "Sherman, Nava [LOD:Telrad:SMTPPART]"
      <nava.sherman@TELRAD.CO.IL>

To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: Chanchal Hassija/HSS)

Subject:  eventbuffersescriptor




Hello!
as I understood the MEGACO/H248 events mechananism (reading the document someone
wrote in this mail group), The  eventbufferdescriptor is used in H248 protocol,
when the eventbuffercontrol parameter = lockstep in order
to decide which events are saved in the event buffer and which are not. (am I
wrong?) when I look on the
commands and descriptor passed between the MGC and MG I see that the
eventbufferdescriptor is only passed
from the MG to the MGC on responses (as response to audit?) but I didn't see how
does the MGC sends this
parameter to the MG. (what I concluded from this that the MG copies the event
descriptor tp the event buffer descriptor
when the event buffer contro = lock step. am I totally wrong.
I am sorry if my question is too naive, I'm new on this protocol.
Nava.

--0__=wulMxxEl3b7KHyxllQnoLi7GNW0M0pZSbOnZ4YIkxJsuKmxp4fuv5nPT
Content-type: text/html;
        name="att1.htm"
Content-Disposition: attachment; filename="att1.htm"
Content-Description: Internet HTML
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXdp
bmRvd3MtMTI1NSIgaHR0cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSJNU0hU
TUwgNS4wMC4yMzE0LjEwMDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hF
QUQ+DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0y
PkhlbGxvITwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iQXJpYWwgKEhlYnJldykiIHNp
emU9Mj5hcyBJIHVuZGVyc3Rvb2QgdGhlIE1FR0FDTy9IMjQ4IGV2ZW50cyANCm1lY2hhbmFuaXNt
IChyZWFkaW5nIHRoZSBkb2N1bWVudCBzb21lb25lIHdyb3RlIGluIHRoaXMgbWFpbCBncm91cCks
IFRoZSAgDQpldmVudGJ1ZmZlcmRlc2NyaXB0b3IgaXMgdXNlZCBpbiBIMjQ4IHByb3RvY29sLCB3
aGVuIHRoZSBldmVudGJ1ZmZlcmNvbnRyb2wgDQpwYXJhbWV0ZXIgPSBsb2Nrc3RlcCBpbiBvcmRl
cjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iQXJpYWwgKEhlYnJldykiIHNpemU9Mj50
byBkZWNpZGUgd2hpY2ggZXZlbnRzIGFyZSBzYXZlZCBpbiB0aGUgDQpldmVudCBidWZmZXIgYW5k
IHdoaWNoIGFyZSBub3QuIChhbSBJIHdyb25nPykgd2hlbiBJIGxvb2sgb24gdGhlPC9GT05UPjwv
RElWPg0KPERJVj48Rk9OVCBmYWNlPSJBcmlhbCAoSGVicmV3KSIgc2l6ZT0yPmNvbW1hbmRzIGFu
ZCBkZXNjcmlwdG9yIHBhc3NlZCBiZXR3ZWVuIA0KdGhlIE1HQyBhbmQgTUcgSSBzZWUgdGhhdCB0
aGUgZXZlbnRidWZmZXJkZXNjcmlwdG9yIGlzIG9ubHkgcGFzc2VkPC9GT05UPjwvRElWPg0KPERJ
Vj48Rk9OVCBmYWNlPSJBcmlhbCAoSGVicmV3KSIgc2l6ZT0yPmZyb20gdGhlIE1HIHRvIHRoZSBN
R0Mgb24gcmVzcG9uc2VzIChhcyANCnJlc3BvbnNlIHRvIGF1ZGl0PykgYnV0IEkgZGlkbid0IHNl
ZSBob3cgZG9lcyB0aGUgTUdDIHNlbmRzIHRoaXM8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh
Y2U9IkFyaWFsIChIZWJyZXcpIiBzaXplPTI+cGFyYW1ldGVyIHRvIHRoZSBNRy4gKHdoYXQgSSBj
b25jbHVkZWQgDQpmcm9tIHRoaXMgdGhhdCB0aGUgTUcgY29waWVzIHRoZSBldmVudCBkZXNjcmlw
dG9yIHRwIHRoZSBldmVudCBidWZmZXIgDQpkZXNjcmlwdG9yPC9GT05UPjwvRElWPg0KPERJVj48
Rk9OVCBmYWNlPSJBcmlhbCAoSGVicmV3KSIgc2l6ZT0yPndoZW4gdGhlIGV2ZW50IGJ1ZmZlciBj
b250cm8gPSBsb2NrIA0Kc3RlcC4gYW0gSSB0b3RhbGx5IHdyb25nLjwvRk9OVD48L0RJVj4NCjxE
SVY+PEZPTlQgZmFjZT0iQXJpYWwgKEhlYnJldykiIHNpemU9Mj5JIGFtIHNvcnJ5IGlmIG15IHF1
ZXN0aW9uIGlzIHRvbyBuYWl2ZSwgDQpJJ20gbmV3IG9uIHRoaXMgcHJvdG9jb2wuPC9GT05UPjwv
RElWPg0KPERJVj48Rk9OVCBmYWNlPSJBcmlhbCAoSGVicmV3KSIgc2l6ZT0yPk5hdmEuPC9GT05U
PiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+DQoNCg==

--0__=wulMxxEl3b7KHyxllQnoLi7GNW0M0pZSbOnZ4YIkxJsuKmxp4fuv5nPT--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Dec  5 08:01:25 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06755
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Dec 2000 08:01:24 -0500 (EST)
Received: from standards (47.234.32.16:1160) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF502@standards.nortelnetworks.com>; Tue, 5 Dec 2000 7:42:10 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 159671 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Dec 2000 07:42:10 -0500
Received: from mail-in.audiocodes.com (AC-INT-LP.ser.netvision.net.il) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBF501@standards.nortelnetworks.com>; Tue, 5 Dec 2000 7:42:09
          -0500
Received: by MAIL-IN with Internet Mail Service (5.5.2650.21) id <YHLA21D8>;
          Tue, 5 Dec 2000 14:58:54 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="windows-1255"
Message-ID:  <81C3E8FE6C0AD4119D49009027C3AAB25DAC59@MAIL-IN>
Date:         Tue, 5 Dec 2000 14:58:54 +0200
Reply-To: Nurit Shenhar <nurit.shenhar@AUDIOCODES.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Nurit Shenhar <nurit.shenhar@AUDIOCODES.COM>
Subject:      MEGACO: DigitMap - some questions
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi list

While implementing the digit map, I read again and again section 7.1.14.5
(DigitMap Procedures) and I have the following questions:

1. In which case to we send a completion event with no match? It seems that
the only possibilities are full match and partial match.

2. In small section 4 in this section, there is a discussion about the 'Z'
option. If I understand correctly, only those alternatives that has 'Z' and
matched the incoming event will stay as candidates, why then it says:
'If alternative event sequences not specifying a long duration event in the
given
position remain in the candidate set after application of the
above rules, the observed event duration is treated as irrelevant in
assessing matches to them'.
?

3. And general question: Does the 'Z' means that when the event is finished
we check it's length, or it means that the alternative can be satisfies
during the event if it is long enough?

Best regards

Nurit Shenhar
AudioCodes Ltd.
Direct: +972-3-539-4155
Tel:     +972-3-539-4000
Fax:    +972-3-539-4040
email:  nurit.shenhar@audiocodes.com

web:    <http://www.audiocodes.com>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Dec  5 10:26:49 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15331
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Dec 2000 10:26:48 -0500 (EST)
Received: from standards (47.234.32.16:2467) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF600@standards.nortelnetworks.com>; Tue, 5 Dec 2000 10:07:25 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 159991 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Dec 2000 10:07:25 -0500
Received: from standards (47.234.32.16:2467) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBBF5FF@standards.nortelnetworks.com>; Tue, 5 Dec 2000 10:07:25
          -0500
Message-ID:  <MEGACO%2000120510072542@STANDARDS.NORTELNETWORKS.COM>
Date:         Tue, 5 Dec 2000 10:07:25 -0500
Reply-To: Tom Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Draft Megaco Agenda
X-To:         Brian.Rosen@MARCONI.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

On Mon, 4 Dec 2000 18:19:16 -0500, Rosen, Brian <Brian.Rosen@MARCONI.COM> wrote:

>Can we not have a re-chartering discussion?
>
>Brian

I can ask Scott.  The message we seemed to get last time was that the list lives on, but it's not clear that the WG needs to continue
its formal existence.

Tom


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Dec  5 11:15:16 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28303
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Dec 2000 11:15:11 -0500 (EST)
Received: from standards (47.234.32.16:4005) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF66F@standards.nortelnetworks.com>; Tue, 5 Dec 2000 10:55:58 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 160136 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Dec 2000 10:55:58 -0500
Received: from netmail.alcatel.com (mail.alcatel.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBF66A@standards.nortelnetworks.com>; Tue, 5 Dec 2000
          10:45:58 -0500
Received: from relay2.usa.alcatel.com (relay2.usa.alcatel.com [143.209.238.7])
          by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id KAA24116 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 5 Dec 2000 10:03:31 -0600
          (CST)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by
          relay2.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id KAA28782 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 5 Dec 2000 10:03:30 -0600
          (CST)
Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com
          [143.209.151.53]) by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP
          id eB5G2bG21923 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 5 Dec
          2000 10:02:37 -0600 (CST)
Received: from usa.alcatel.com (localhost [127.0.0.1]) by
          sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id
          eB5G2b015968 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 5 Dec
          2000 10:02:37 -0600 (CST)
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="------------EF03480A88BB1DDD50B46534"
Message-ID:  <3A2D119D.9AD997CF@usa.alcatel.com>
Date:         Tue, 5 Dec 2000 10:02:37 -0600
Reply-To: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Subject:      ServiceChange corrections in Implementers Guide
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

Hi Christian

I don't know if this was pointed out already.
I am looking at H248_Implementors_guide_approved.zip.

The change for Section 6.3  Cold Start has the following:
"If the MGC accepts the MG, it will send a Transaction Reply, with the
ServiceChangeMgcId
set to itself."

The change for Section 11.2 Cold Start has the following:
"If the MGC accepts the MG's resignation, it sends a Transaction Reply
not including a
ServiceChangeMgcId parameter."

This 2 statements contradict each other.
I think originally it was always "not" including a ServiceChangeMgcId
parameter.

Also additional words might be added to clearly stated that
"If the MG receives a Transaction Reply that includes a
ServiceChangeMgcId parameter, it sends
a ServiceChange w/a method of Restart to the MGC specified in the
ServiceChangeMgcId."

Otherwise someone might get confused and use ServiceChange w/a method of
handoff.

Chuong

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



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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi Christian
<p>I&nbsp;don't know if this was pointed out already.
<br>I&nbsp;am looking at H248_Implementors_guide_approved.zip.
<p>The change for Section 6.3&nbsp; Cold Start has the following:
<br>"If the MGC accepts the MG, it will send a Transaction Reply, with
the ServiceChangeMgcId
<br>set to itself."
<p>The change for Section 11.2 Cold Start has the following:
<br>"If the MGC accepts the MG's resignation, it sends a Transaction Reply
<b>not </b>including a
<br>ServiceChangeMgcId parameter."
<p>This 2 statements contradict each other.
<br>I&nbsp;think originally it was always "not" including a ServiceChangeMgcId
parameter.
<p>Also additional words might be added to clearly stated that
<br>"If the MG receives a Transaction Reply that includes a ServiceChangeMgcId
parameter, it sends
<br>a ServiceChange <b>w/a method of Restart </b>to the MGC specified in
the ServiceChangeMgcId."
<p>Otherwise someone might get confused and use ServiceChange w/a method
of handoff.
<p>Chuong
<pre>--&nbsp;
&nbsp; Alcatel USA, Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Internet: Chuong.Nguyen@usa.alcatel.com
&nbsp; 1000 Coit Road Plano, Texas 75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613
&nbsp; **** The opinions expressed are not those of Alcatel USA, Inc ****</pre>
&nbsp;</html>

--------------EF03480A88BB1DDD50B46534--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Dec  5 11:27:21 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01183
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Dec 2000 11:27:20 -0500 (EST)
Received: from standards (47.234.32.16:4005) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF68D@standards.nortelnetworks.com>; Tue, 5 Dec 2000 11:08:04 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 160177 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Dec 2000 11:08:03 -0500
Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBF68C@standards.nortelnetworks.com>; Tue, 5 Dec 2000
          11:08:03 -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 LAA04135
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 5 Dec 2000 11:25:39
          -0500 (EST)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by
          hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id LAA04121
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 5 Dec 2000 11:25:38
          -0500 (EST)
Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id LAA28399; Tue, 5 Dec
          2000 11:25:35 -0500
Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id
          LAA28396; Tue, 5 Dec 2000 11:25:35 -0500
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Original-To: MEGACO@STANDARDS.NORTELNETWORKS.COM, "Taylor,
             Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
References: <28560036253BD41191A10000F8BCBD1103061EC7@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3A2D16B1.4C557BE8@lucent.com>
Date:         Tue, 5 Dec 2000 11:24:17 -0500
Reply-To: Troy Cauble <troy@bell-labs.com>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Troy Cauble <troy@LUCENT.COM>
Subject:      Re: RFC 3015 & Draft Megaco Agenda
X-To:         "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

"Taylor, Tom-PT [NORSE:B901:EXCH]" wrote:
>
> At least on the web interface (the only way I seem to be able to get to look
> at Megaco correspondence these days), the announce of publication of RFC
> 3015 seemed to be garbled.  RFC 3015 reproduces the content of H.248 as
> decided last June.  It obsoletes the combination of RFCs 2885 and 2886, but
> does not change what was specified by the combination of those two
> documents.
>
> May we find a less process-ridden way to put out any updates to the
> protocol!
>
> Tom Taylor
> +1 613 736 0961
> taylor@nortelnetworks.com

Please excuse me for not keeping up, but I have several questions
on the state of H.248/Megaco in the two standards bodies.

I understand that RFC 3015 obsoletes 2885 and 2886.  Does it have
ONLY the information in those documents or does it contain some
of the issues resolved in this list?  (Like those in the ITU-T
Implementor's Guide.)

Is the Implementor's Guide considered "done", or is it still a
living document?

I've primarily been working from the ITU-T documents, mainly
because the IG was a living document and RFC 2886 was written
in August.  Are the two protocols still in synch?
Does the 6/00 ITU-T doc plus the IG cover everything in
RFCs 2885 and 2886?  Everything in 3015?


Also, some of the comments in the "Draft Megaco Agenda" thread
make me think you're close to shutting down the working group.
IMO there are still some significant under specified portions
of the protocol, particularly in the ASN.1 encoding.  Does the
Megaco working group think the protocol is "done"?

-troy


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Dec  5 11:37:44 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03525
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Dec 2000 11:37:43 -0500 (EST)
Received: from standards (47.234.32.16:4005) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF6AA@standards.nortelnetworks.com>; Tue, 5 Dec 2000 11:18:39 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 160211 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Dec 2000 11:18:39 -0500
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBBF6A9@standards.nortelnetworks.com>; Tue, 5 Dec 2000 11:18:34
          -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id LAA22087; Tue, 5 Dec 2000 11:36:07 -0500 (EST)
Received: from stl-server-01.pit.comms.marconi.com
          (stl-server-01.pit.comms.marconi.com [169.144.36.27]) by
          mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA09083;
          Tue, 5 Dec 2000 11:36:07 -0500 (EST)
Received: by stl-server-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <YB6WSYZJ>; Tue, 5 Dec 2000 11:36:08 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF01A6EB27@whq-msgusr-02.pit.comms.marconi.com>
Date:         Tue, 5 Dec 2000 11:35:57 -0500
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: RFC 3015 & Draft Megaco Agenda
X-To:         Troy Cauble <troy@bell-labs.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

RFC 3015 and the ITU Recommendation H.248 are identical except for
boilerplate.
RFC 3015 is RFC 2885 with the changes in RFC 2886.  There could be some
minor
differences between the wording of 3015 and 2885 updated by 2886, but there
should be none between the ITU Recommendation and 3015.

Christian Groves assures us that the Implementor's Guide is a living
document.
The guide applies to both 3015 and H.248 equally.

I personally think we need to recharter the Megaco WG.

Brian



> -----Original Message-----
> From: Troy Cauble [mailto:troy@LUCENT.COM]
> Sent: Tuesday, December 05, 2000 11:24 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: RFC 3015 & Draft Megaco Agenda
>
>
> "Taylor, Tom-PT [NORSE:B901:EXCH]" wrote:
> >
> > At least on the web interface (the only way I seem to be
> able to get to look
> > at Megaco correspondence these days), the announce of
> publication of RFC
> > 3015 seemed to be garbled.  RFC 3015 reproduces the content
> of H.248 as
> > decided last June.  It obsoletes the combination of RFCs
> 2885 and 2886, but
> > does not change what was specified by the combination of those two
> > documents.
> >
> > May we find a less process-ridden way to put out any updates to the
> > protocol!
> >
> > Tom Taylor
> > +1 613 736 0961
> > taylor@nortelnetworks.com
>
> Please excuse me for not keeping up, but I have several questions
> on the state of H.248/Megaco in the two standards bodies.
>
> I understand that RFC 3015 obsoletes 2885 and 2886.  Does it have
> ONLY the information in those documents or does it contain some
> of the issues resolved in this list?  (Like those in the ITU-T
> Implementor's Guide.)
>
> Is the Implementor's Guide considered "done", or is it still a
> living document?
>
> I've primarily been working from the ITU-T documents, mainly
> because the IG was a living document and RFC 2886 was written
> in August.  Are the two protocols still in synch?
> Does the 6/00 ITU-T doc plus the IG cover everything in
> RFCs 2885 and 2886?  Everything in 3015?
>
>
> Also, some of the comments in the "Draft Megaco Agenda" thread
> make me think you're close to shutting down the working group.
> IMO there are still some significant under specified portions
> of the protocol, particularly in the ASN.1 encoding.  Does the
> Megaco working group think the protocol is "done"?
>
> -troy
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Dec  5 12:44:47 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21429
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Dec 2000 12:44:46 -0500 (EST)
Received: from standards (47.234.32.16:4005) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF6FC@standards.nortelnetworks.com>; Tue, 5 Dec 2000 12:25:38 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 160306 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Dec 2000 12:25:38 -0500
Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBF6FB@standards.nortelnetworks.com>; Tue, 5 Dec 2000
          12:25:37 -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 MAA25106
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 5 Dec 2000 12:43:13
          -0500 (EST)
Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by
          auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA25092
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 5 Dec 2000 12:43:12
          -0500 (EST)
Received: from lucent.com (pctla [135.3.130.39]) by teton.mh.lucent.com
          (8.8.8+Sun/8.8.8) with ESMTP id MAA13203 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 5 Dec 2000 12:41:37 -0500
          (EST)
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------ADF4B61114F0602C85456530"
Message-ID:  <3A2D296D.4192D3EA@lucent.com>
Date:         Tue, 5 Dec 2000 12:44:13 -0500
Reply-To: Terry L Anderson <tla@LUCENT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Terry L Anderson <tla@LUCENT.COM>
Organization: Lucent Technologies
Subject:      timestamp in registration replies
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.
--------------ADF4B61114F0602C85456530
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Section 7.2.8 of H.248 states:
"The TimeStamp parameter shall be sent with a registration command and
its response."

There is a TimeStamp optional in ServiceChangeParm of both ASN.1 and
ABNF but it is NOT available in either ServiceChangeResParm (ASN.1) or
servChgReplyParm (ABNF) so I see no way to include it in the
registration response.

I do not see any correction to the text or to the ASN.1 or ABNF specs
for this in the Implementors' Guide.

--
------------------------------------------------------------
Terry L Anderson              mailto:tla@lucent.com
Tel:908.582.7013   Fax:908.582.6729
Pager:800.759.8352 pin 1704572   1704572@skytel.com
Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla


--------------ADF4B61114F0602C85456530
Content-Type: text/x-vcard; charset=us-ascii;
 name="tla.vcf"
Content-Description: Card for Terry L Anderson
Content-Disposition: attachment;
 filename="tla.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard
n:Anderson;Terry L
tel;pager:800.759.8352 pin 1704572
tel;fax:908.582.6729
tel;work:908.582.7013
x-mozilla-html:TRUE
url:http://its.lucent.com/~tla
org:Lucent / InterNetworking Systems;VoIP Access Networks / Applications Group
version:2.1
email;internet:tla@lucent.com
title:DMTS
adr;quoted-printable:;;600 Mountain Av=0D=0ARm 2B-121;Murray Hill;NJ;07974;USA
note;quoted-printable:http://www.gti.net/tla  or http://teton.mh.lucent.com/~tla (Lucent internal)=0D=0A18E343126 / 10034134
x-mozilla-cpt:;-23792
fn:Terry L Anderson
end:vcard

--------------ADF4B61114F0602C85456530--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Dec  5 12:48:34 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21932
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Dec 2000 12:48:33 -0500 (EST)
Received: from standards (47.234.32.16:4005) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF70F@standards.nortelnetworks.com>; Tue, 5 Dec 2000 12:28:01 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 160299 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Dec 2000 12:28:01 -0500
Received: from netmail.alcatel.com (mail.alcatel.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBF6F4@standards.nortelnetworks.com>; Tue, 5 Dec 2000
          12:18:01 -0500
Received: from relay2.usa.alcatel.com (relay2.usa.alcatel.com [143.209.238.7])
          by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id LAA08622 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 5 Dec 2000 11:35:33 -0600
          (CST)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by
          relay2.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id LAA00757 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 5 Dec 2000 11:35:32 -0600
          (CST)
Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com
          [143.209.151.53]) by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP
          id eB5HYgG02996 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 5 Dec
          2000 11:34:42 -0600 (CST)
Received: from usa.alcatel.com (localhost [127.0.0.1]) by
          sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id
          eB5HYg016018 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 5 Dec
          2000 11:34:42 -0600 (CST)
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="------------9C2F6D2C103C7B87ADD14280"
Message-ID:  <3A2D2732.894B17D3@usa.alcatel.com>
Date:         Tue, 5 Dec 2000 11:34:42 -0600
Reply-To: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Subject:      [Fwd: ServiceChange corrections in Implementers Guide]
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

Ops.  One more point in Section 11. last paragraph

"The MG shall issue error 505 - Command Received before Restart
Response."
The "MG" should be "MGC".

This also brings up an interesting point.

For sure error 505 applies to all commands before Restart but there are
exception for ServiceChange.

For ServiceChange w/method Forced/Graceful, MGC should response w/error
505.
For ServiceChange w/method HandOff or Failover, MGC should either accept
the
registration or provide alternative MGC to try.

Are the above assumption correct?

Thanks
Chuong

Chuong Nguyen wrote:

> Hi Christian
>
> I don't know if this was pointed out already.
> I am looking at H248_Implementors_guide_approved.zip.
>
> The change for Section 6.3  Cold Start has the following:
> "If the MGC accepts the MG, it will send a Transaction Reply, with the
> ServiceChangeMgcId
> set to itself."
>
> The change for Section 11.2 Cold Start has the following:
> "If the MGC accepts the MG's resignation, it sends a Transaction Reply
> not including a
> ServiceChangeMgcId parameter."
>
> This 2 statements contradict each other.
> I think originally it was always "not" including a ServiceChangeMgcId
> parameter.
>
> Also additional words might be added to clearly stated that
> "If the MG receives a Transaction Reply that includes a
> ServiceChangeMgcId parameter, it sends
> a ServiceChange w/a method of Restart to the MGC specified in the
> ServiceChangeMgcId."
>
> Otherwise someone might get confused and use ServiceChange w/a method
> of handoff.
>
> Chuong
>
> --
>   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>   **** The opinions expressed are not those of Alcatel USA, Inc ****
>
>

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



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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Ops.&nbsp; One more point in Section 11. last paragraph
<p>"The <b>MG</b> shall issue error 505 - Command Received before Restart
Response."
<br>The "MG" should be "MGC".
<p>This also brings up an interesting point.
<p>For sure error 505 applies to all commands before Restart but there
are exception for ServiceChange.
<p>For ServiceChange w/method Forced/Graceful, MGC should response w/error
505.
<br>For ServiceChange w/method HandOff or Failover, MGC&nbsp;should either
accept the
<br>registration or provide alternative MGC to try.
<p>Are the above assumption correct?
<p>Thanks
<br>Chuong
<p>Chuong Nguyen wrote:
<blockquote TYPE=CITE>Hi Christian
<p>I don't know if this was pointed out already.
<br>I am looking at H248_Implementors_guide_approved.zip.
<p>The change for Section 6.3&nbsp; Cold Start has the following:
<br>"If the MGC accepts the MG, it will send a Transaction Reply, with
the ServiceChangeMgcId
<br>set to itself."
<p>The change for Section 11.2 Cold Start has the following:
<br>"If the MGC accepts the MG's resignation, it sends a Transaction Reply
<b>not
</b>including
a
<br>ServiceChangeMgcId parameter."
<p>This 2 statements contradict each other.
<br>I think originally it was always "not" including a ServiceChangeMgcId
parameter.
<p>Also additional words might be added to clearly stated that
<br>"If the MG receives a Transaction Reply that includes a ServiceChangeMgcId
parameter, it sends
<br>a ServiceChange <b>w/a method of Restart </b>to the MGC specified in
the ServiceChangeMgcId."
<p>Otherwise someone might get confused and use ServiceChange w/a method
of handoff.
<p>Chuong
<pre>--&nbsp;
&nbsp; Alcatel USA, Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Internet: Chuong.Nguyen@usa.alcatel.com
&nbsp; 1000 Coit Road Plano, Texas 75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613
&nbsp; **** The opinions expressed are not those of Alcatel USA, Inc ****</pre>
&nbsp;</blockquote>

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

--------------9C2F6D2C103C7B87ADD14280--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Dec  5 14:36:14 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA25598
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Dec 2000 14:36:13 -0500 (EST)
Received: from standards (47.234.32.16:4888) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF7AF@standards.nortelnetworks.com>; Tue, 5 Dec 2000 14:17:03 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 160530 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Dec 2000 14:17:02 -0500
Received: from redball.dynamicsoft.com (216.173.40.51:38669) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBF7A8@standards.nortelnetworks.com>; Tue, 5 Dec 2000
          14:07:01 -0500
Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by
          redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id
          OAA21417 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 5 Dec 2000
          14:27:08 -0500 (EST)
Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service
          (5.5.2650.21) id <X2075S1A>; Tue, 5 Dec 2000 14:22:32 -0500
X-MS-TNEF-Correlator: <B65B4F8437968F488A01A940B21982BFB3CBBD@DYN-EXCH-001.dynamicsoft.com>
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Message-ID:  <B65B4F8437968F488A01A940B21982BFB3CBBD@DYN-EXCH-001.dynamicsoft.com>
Date:         Tue, 5 Dec 2000 14:22:26 -0500
Reply-To: NAV for Microsoft Exchange-DYN-EXCH-001              <NAVMSE-DYN-EXCH-001@DYNAMICSOFT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: NAV for Microsoft Exchange-DYN-EXCH-001              <NAVMSE-DYN-EXCH-001@DYNAMICSOFT.COM>
Subject:      Norton AntiVirus detected and quarantined a virus in a message yo
              u sent.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Recipient of the infected attachment:  Jonathan Rosenberg\megaco
Subject of the message:  Check this
One or more attachments were quarantined.
  Attachment LINKS.VBS was Quarantined for the following reasons:
    Virus VBS.Freelink was found.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Dec  5 17:43:59 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02608
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 5 Dec 2000 17:43:58 -0500 (EST)
Received: from standards (47.234.32.16:3914) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBF8B9@standards.nortelnetworks.com>; Tue, 5 Dec 2000 17:24:51 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 160878 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Dec 2000 17:24:51 -0500
Received: from zrchh190 (47.158.65.22:33187) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBBF8AE@standards.nortelnetworks.com>; Tue, 5 Dec 2000 17:14:51
          -0500
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by zrchh190;
          Tue, 5 Dec 2000 16:29:58 -0600
Received: from zcard015.ca.nortel.com (actually zcard015) by
          ertpg14e1.nortelnetworks.com; Tue, 5 Dec 2000 17:29:02 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id
          <Y239L5DN>; Tue, 5 Dec 2000 17:29:01 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
X-Orig: <taylor@nortelnetworks.com>
Message-ID:  <28560036253BD41191A10000F8BCBD11030A5C69@zcard00g.ca.nortel.com>
Date:         Tue, 5 Dec 2000 17:29:00 -0500
Reply-To: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Subject:      Re: RFC 3015 & Draft Megaco Agenda
X-To:         Troy Cauble <troy@bell-labs.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi.

> -----Original Message-----
> From: Troy Cauble [mailto:troy@lucent.com]
> Sent: Tuesday, December 05, 2000 11:24 AM
...
>
> Please excuse me for not keeping up, but I have several questions
> on the state of H.248/Megaco in the two standards bodies.
>
> I understand that RFC 3015 obsoletes 2885 and 2886.  Does it have
> ONLY the information in those documents or does it contain some
> of the issues resolved in this list?  (Like those in the ITU-T
> Implementor's Guide.)

[PTT] RFC 3015 contains ONLY the information in 2885 and 2886.

>
> Is the Implementor's Guide considered "done", or is it still a
> living document?

It is a living document.

>
> I've primarily been working from the ITU-T documents, mainly
> because the IG was a living document and RFC 2886 was written
> in August.  Are the two protocols still in synch?
> Does the 6/00 ITU-T doc plus the IG cover everything in
> RFCs 2885 and 2886?  Everything in 3015?

[PTT]
The IG is additional to the RFC.  BTW, August is the publication date of
2886, but it was actually written last spring.  Here is the key equation:
 2885 + 2886 = 3015 = H.248 (June 2000)
The Implementor's Guide captures corrections and clarifications made since
last June's Decision.  It is accepted by both the ITU-T and the IETF, even
though the IETF doesn't usually have Implementor's Guides as such.

>
>
> Also, some of the comments in the "Draft Megaco Agenda" thread
> make me think you're close to shutting down the working group.
> IMO there are still some significant under specified portions
> of the protocol, particularly in the ASN.1 encoding.  Does the
> Megaco working group think the protocol is "done"?

[PTT]
IETF Working Groups are established with charters.  Except for the MIB, we
have fulfilled ours.  The IESG has to decide whether we should be
rechartered to continue the work, or whether we should continue informally
on the list with SG 16 the only formal mechanism for update.  You should be
aware that RFCs don't have to originate from Working Groups, so we can
continue to ask the IESG to approve Megaco-related RFCs and back up our
requests with the statement that there is consensus on the Megaco discussion
list (still 1100-plus people!) when that statement applies.

BTW, in response to Brian's earlier note, Scott says it is OK to have a
rechartering discussion but there are no guarantees the IESG will act on it.
One reason why they might not is because our heavily-loaded ADs need to turn
their attention elsewhere and figure that Megaco is working without their
formal support.

>
> -troy
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec  6 00:19:02 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA17444
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Dec 2000 00:19:01 -0500 (EST)
Received: from standards (47.234.32.16:3752) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBFB7D@standards.nortelnetworks.com>; Tue, 5 Dec 2000 23:59:57 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 161869 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 5 Dec 2000 23:59:56 -0500
Received: from mailcity.com (fes-qout.whowhere.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBFB7C@standards.nortelnetworks.com>; Tue, 5 Dec 2000
          23:59:56 -0500
Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Tue Dec  5 21:17:11
          2000
Mime-Version: 1.0
X-Sent-Mail: off
X-Mailer: MailCity Service
X-Sender-Ip: 12.40.232.2
Content-Type: text/plain; charset=us-ascii
Content-Language: en
Content-Transfer-Encoding: 7bit
Message-ID:  <GDJDHGIODKCCBAAA@mailcity.com>
Date:         Tue, 5 Dec 2000 21:17:11 -0800
Reply-To: kris_albert@lycos.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Kris Albert <kris_albert@lycos.com>
Organization: Lycos Communications  (http://comm.lycos.com:80)
Subject:      DigMap Related Questions
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi all,
      I have few questions related to the digitmaps

 1. What is the lifespan of a digitmap on a termination? Deos it have anything  to do with what context (Null/Non-Null) termination is in when the digit map  is defined fo the termination?

   2.  On the deletion of a ephemeral termination, Is it required to remove all  the digitmap definitions, which are associated with this termination.

 3. When a parmanent termination moves to NULL Context, will it retain all  the digitmap defined on it(when it was in the context), or will it retain
 only the default(/provisioned) digitmap definitions(if any) on this  termination?

 Are DigMaps defined while termId is in Null context treated as default values  which are restored when the termIf returns to NULL context.



 Thanks in advance,

 kris



Great Gift Idea!  FREE cell phone, internet ready at Lycos Marketplace
 http://www.inphonic.lycos.com/redirect.asp?referringpage=www.lycosd1


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec  6 01:53:31 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA27726
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Dec 2000 01:53:31 -0500 (EST)
Received: from standards (47.234.32.16:2095) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBFBFF@standards.nortelnetworks.com>; Wed, 6 Dec 2000 1:34:19 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 162048 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Dec 2000 01:34:19 -0500
Received: from hindon.hss.co.in (202.54.26.202:52588) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBFBFE@standards.nortelnetworks.com>; Wed, 6 Dec 2000 1:34:13
          -0500
Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in
          (8.10.0/8.10.0) with SMTP id eB66qta13720 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 6 Dec 2000 12:23:01 +0530
          (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          652569AD.0023FDC6 ; Wed, 6 Dec 2000 12:03:07 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <652569AD.0023FD07.00@sandesh.hss.hns.com>
Date:         Wed, 6 Dec 2000 12:14:39 +0530
Reply-To: ssikri@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Sachin Sikri <ssikri@HSS.HNS.COM>
Subject:      Conflicting packageIDs
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi

 Text Telephone package defined in Annex F and Keypad Package defined in Annnex
G have conflicting package IDs as 0x0016.
As per my thinking package ID for Text Telephone package should be 0x0010
(Correct me if i am wrong).
Also if anybody can tell me the package ID for R2 package.

Regards
Sachin Sikri
Hughes Software System


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec  6 03:25:19 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA00297
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Dec 2000 03:25:18 -0500 (EST)
Received: from standards (47.234.32.16:1056) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBFC31@standards.nortelnetworks.com>; Wed, 6 Dec 2000 3:06:05 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 162110 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Dec 2000 03:06:04 -0500
Received: from hindon.hss.co.in (202.54.26.202:55353) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBFC30@standards.nortelnetworks.com>; Wed, 6 Dec 2000 3:06:02
          -0500
Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in
          (8.10.0/8.10.0) with SMTP id eB68Owg18067 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 6 Dec 2000 13:54:59 +0530
          (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          652569AD.002D07FE ; Wed, 6 Dec 2000 13:41:51 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <652569AD.002D0674.00@sandesh.hss.hns.com>
Date:         Wed, 6 Dec 2000 13:47:47 +0530
Reply-To: chassija@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chanchal Hassija <chassija@HSS.HNS.COM>
Subject:      ServiceChange - Failover
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hello All,



      The scenario is one MGC and two MGs...one active and one standby. On
      faliure of active MG, standby MG is taking over.

      It is the responsibility of which MG to send the ServiceChange (failover
      method and MG impending failure as the reason). As per 11.4 section in the
      protocol document, it appears that it is the responsibilityof the active
      MG(MG which is going down). But if Active MG is not capable of sending a
      message to MGC, how shall MGC come to know that the standby MG is now
      active MG.

      Is it not better that the MG which gets active after switchover sends the
      ServiceChange ?



Thanks for your time

Chan...


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec  6 06:52:26 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA16465
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Dec 2000 06:52:24 -0500 (EST)
Received: from standards (47.234.32.16:4989) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBFD1D@standards.nortelnetworks.com>; Wed, 6 Dec 2000 6:32:49 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 162299 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Dec 2000 06:32:49 -0500
Received: from ties.itu.ch by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFBBFCC8@standards.nortelnetworks.com>;
          Wed, 6 Dec 2000 6:22:48 -0500
Received: from ericsson.com ([156.106.209.13]) by ties.itu.ch (8.9.3/8.9.3)
          with ESMTP id MAA13069; Wed, 6 Dec 2000 12:40:24 +0100 (MET)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF01A6EB27@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3A2E0BC1.38788240@ericsson.com>
Date:         Wed, 6 Dec 2000 20:49:53 +1100
Reply-To: Christian Groves <Christian.Groves@ERICSSON.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Christian Groves <Christian.Groves@ERICSSON.COM>
Subject:      Re: RFC 3015 & Draft Megaco Agenda
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day all,

I have the same understanding as Brian. 3015 is the same as the ITU
Recommendation. The Implementors' guide is a living document.

An information draft/rfc should be issued for the approved version from
the last SG16 meeting to make it available more generally. I'm still
collecting points for the next approved version but i'll be a little
slow over the next month dues to holidays.

As part of the recharter discussions H.248v2 needs to be considered.
Someone from the Megaco group should be responsible (if not Tom) for
collating draft/mails etc for input to the H.248v2 protocol.

Cheers, Christian

"Rosen, Brian" wrote:
>
> RFC 3015 and the ITU Recommendation H.248 are identical except for
> boilerplate.
> RFC 3015 is RFC 2885 with the changes in RFC 2886.  There could be some
> minor
> differences between the wording of 3015 and 2885 updated by 2886, but there
> should be none between the ITU Recommendation and 3015.
>
> Christian Groves assures us that the Implementor's Guide is a living
> document.
> The guide applies to both 3015 and H.248 equally.
>
> I personally think we need to recharter the Megaco WG.
>
> Brian
>
> > -----Original Message-----
> > From: Troy Cauble [mailto:troy@LUCENT.COM]
> > Sent: Tuesday, December 05, 2000 11:24 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: RFC 3015 & Draft Megaco Agenda
> >
> >
> > "Taylor, Tom-PT [NORSE:B901:EXCH]" wrote:
> > >
> > > At least on the web interface (the only way I seem to be
> > able to get to look
> > > at Megaco correspondence these days), the announce of
> > publication of RFC
> > > 3015 seemed to be garbled.  RFC 3015 reproduces the content
> > of H.248 as
> > > decided last June.  It obsoletes the combination of RFCs
> > 2885 and 2886, but
> > > does not change what was specified by the combination of those two
> > > documents.
> > >
> > > May we find a less process-ridden way to put out any updates to the
> > > protocol!
> > >
> > > Tom Taylor
> > > +1 613 736 0961
> > > taylor@nortelnetworks.com
> >
> > Please excuse me for not keeping up, but I have several questions
> > on the state of H.248/Megaco in the two standards bodies.
> >
> > I understand that RFC 3015 obsoletes 2885 and 2886.  Does it have
> > ONLY the information in those documents or does it contain some
> > of the issues resolved in this list?  (Like those in the ITU-T
> > Implementor's Guide.)
> >
> > Is the Implementor's Guide considered "done", or is it still a
> > living document?
> >
> > I've primarily been working from the ITU-T documents, mainly
> > because the IG was a living document and RFC 2886 was written
> > in August.  Are the two protocols still in synch?
> > Does the 6/00 ITU-T doc plus the IG cover everything in
> > RFCs 2885 and 2886?  Everything in 3015?
> >
> >
> > Also, some of the comments in the "Draft Megaco Agenda" thread
> > make me think you're close to shutting down the working group.
> > IMO there are still some significant under specified portions
> > of the protocol, particularly in the ASN.1 encoding.  Does the
> > Megaco working group think the protocol is "done"?
> >
> > -troy
> >


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec  6 06:52:27 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA16481
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Dec 2000 06:52:26 -0500 (EST)
Received: from standards (47.234.32.16:4989) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBFD24@standards.nortelnetworks.com>; Wed, 6 Dec 2000 6:32:54 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 162300 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Dec 2000 06:32:54 -0500
Received: from ties.itu.ch by standards.nortelnetworks.com (LSMTP for Windows
          NT v1.1b) with SMTP id <0.FFBBFCC9@standards.nortelnetworks.com>;
          Wed, 6 Dec 2000 6:22:53 -0500
Received: from ericsson.com ([156.106.209.13]) by ties.itu.ch (8.9.3/8.9.3)
          with ESMTP id MAA08009; Wed, 6 Dec 2000 12:40:07 +0100 (MET)
X-Mailer: Mozilla 4.72 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <006501c0592c$666063c0$3bc9a8c0@avinash>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3A2522C0.9AF5011B@ericsson.com>
Date:         Thu, 30 Nov 2000 02:37:36 +1100
Reply-To: Christian Groves <Christian.Groves@ERICSSON.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Christian Groves <Christian.Groves@ERICSSON.COM>
Subject:      Re: Definition of media Descriptor in ABNF & ASN.1
X-To:         Avinash Prakash <avinash@NETLAB.HCLTECH.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

G'Day Avinash,

The Media descriptor according to the protocol text can only have a
stream descriptors. The ASN1 also allows for having multiple descriptors
in the Media descriptor.

Cheers, Christian



Avinash Prakash wrote:
>
> Hi,
>
> According to ABNF, a media Descriptor can have a sequence of  media
> Parameter. In ASN.1, however, it is not so.
> Is there a discrepancy in the two or I am missing something?
> Can we be more claer as to what is intended?
>
> Regards,
> Avinash.
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec  6 08:18:02 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03960
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Dec 2000 08:18:01 -0500 (EST)
Received: from standards (47.234.32.16:4061) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBFD8A@standards.nortelnetworks.com>; Wed, 6 Dec 2000 7:58:43 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 162539 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Dec 2000 07:58:43 -0500
Received: from smtp4.cluster.oleane.net (195.25.12.62:4251) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBFD89@standards.nortelnetworks.com>; Wed, 6 Dec 2000 7:58:42
          -0500
Received: from oleane (dyn-1-1-091.Vin.dialup.oleane.fr [195.25.4.91]) by
          smtp4.cluster.oleane.net with SMTP id eB6DG3i92156 for
          <megaco@standards.nortelnetworks.com>; Wed, 6 Dec 2000 14:16:03 +0100
          (CET)
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_0075_01C05F8F.62802060"
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:  <007801c05f87$011745e0$8001a8c0@oleane.com>
Date:         Wed, 6 Dec 2000 14:18:20 +0100
Reply-To: Peter Lewis <peter.lewis@UPPERSIDE.FR>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Peter Lewis <peter.lewis@UPPERSIDE.FR>
Subject:      IP.Net call for papers
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

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

=20
The dead line for the IP.Net call for papers has been postponed to =
December 22nd.
Get more details at:
http://www.upperside.fr/baipnet.htm
Due to the success of the exhibition part, the event will take place =
from 19 to 22 June at the Sofitel Hotel in Paris.


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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2><FONT face=3DArial size=3D2>&nbsp;
<DIV><FONT color=3D#000000 size=3D2>The dead line for the IP.Net call =
for papers has=20
been postponed to December 22nd.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Get more details at:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><A=20
href=3D"http://www.upperside.fr/baipnet.htm">http://www.upperside.fr/baip=
net.htm</A></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Due to the success of the exhibition =
part, the=20
event will take place from 19 to 22 June at the Sofitel Hotel in=20
Paris.</FONT></DIV>
<DIV>&nbsp;</DIV></FONT></FONT></DIV></BODY></HTML>

------=_NextPart_000_0075_01C05F8F.62802060--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec  6 08:34:12 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07605
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Dec 2000 08:34:11 -0500 (EST)
Received: from standards (47.234.32.16:4061) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBFDBC@standards.nortelnetworks.com>; Wed, 6 Dec 2000 8:14:47 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 162606 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Dec 2000 08:14:47 -0500
Received: from mailcity.com (fes-qout.whowhere.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBFDBB@standards.nortelnetworks.com>; Wed, 6 Dec 2000 8:14:47
          -0500
Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Wed Dec  6 05:32:14
          2000
Mime-Version: 1.0
X-Sent-Mail: off
X-Mailer: MailCity Service
X-Sender-Ip: 12.40.232.2
Content-Type: text/plain; charset=us-ascii
Content-Language: en
Content-Transfer-Encoding: 7bit
Message-ID:  <EAPNMBALAJNDBAAA@mailcity.com>
Date:         Wed, 6 Dec 2000 05:32:14 -0800
Reply-To: kris_albert@lycos.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Kris Albert <kris_albert@lycos.com>
Organization: Lycos Communications  (http://comm.lycos.com:80)
Subject:      Error code for TermId not in Context
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi List!
I have a query regarding the error code to be used when the specific termination id in a command request is not present in the context Id(specific/wildcarded) specified in the action request containing that command.
My understanding is that it should use Error code 431- "No TerminationId matched a wildcard" for these error cases too.
Am I right ? or should some other error code needs to be used or DEFINED?

Thanks in advance,
Kris



Great Gift Idea!  FREE cell phone, internet ready at Lycos Marketplace
 http://www.inphonic.lycos.com/redirect.asp?referringpage=www.lycosd1


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec  6 09:10:02 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15565
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Dec 2000 09:10:02 -0500 (EST)
Received: from standards (47.234.32.16:4061) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBFDFF@standards.nortelnetworks.com>; Wed, 6 Dec 2000 8:50:47 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 162676 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Dec 2000 08:50:47 -0500
Received: from zmers013 (47.124.1.40:60031) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBBFDF2@standards.nortelnetworks.com>; Wed, 6 Dec 2000 8:40:47
          -0500
Received: from smtprch1.nortel.com (actually erchg0j) by zmers013; Wed, 6 Dec
          2000 08:58:02 -0500
Received: from zcard015.ca.nortel.com (actually zcard015) by
          smtprch1.nortel.com; Wed, 6 Dec 2000 07:57:56 -0600
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id
          <Y239MBYS>; Wed, 6 Dec 2000 08:57:51 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD11030A5FAA@zcard00g.ca.nortel.com>
Date:         Wed, 6 Dec 2000 08:57:39 -0500
Reply-To: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Subject:      Re: 49th IETF WG Agenda -- MEGACO
X-To:         agenda@ietf.org
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Draft Megaco Agenda (updated from Monday's version)

1. 9:00 Agenda Bashing (2 minutes)

2. 9:02 ITU-T SG 16 Status
                  Tom Taylor (5 minutes)

3. 9:07 Completion of charter items
   (a) MIB (draft-ietf-megaco-mib-01.txt)
                  Matt Holdrege (20 minutes)
   (b) NAS package (draft-ietf-megaco-naspkg-02.txt)
                  Tom Taylor (3 minutes)

4. 9:30 Well-aged package proposals
   (a) draft-boyle-megaco-tonepkgs-01.txt
   (b) draft-boyle-megaco-alerting-00.txt
   (c) draft-cornel-megaco-enhancedd-00.txt
                  Michael Brown (8 minutes)
   (d) draft-scoggins-megaco-pktnetpkg-00.txt
                  Sophia Scoggins (3 minutes)
   Contingency: 5 minutes

5. 9:46 CAS design team report
                  Michael Brown (10 minutes)

6. 9:56 ISDN
   -- draft-bouwen-megaco-isdn-bcp-00.txt
   -- draft-bouwen-megaco-isdn-data-00.txt
   -- draft-bouwen-megaco-isdn-pack-00.txt
                  Jan Bouwen (15 minutes)

7. 10:11 Other Proposals
    (a) draft-rosen-megaco-namepatterns-00.txt
                  Brian Rosen (10 minutes)
    (b) draft-cutler-megaco-recvpkg-01.txt
                  Wayne Cutler (10 minutes)
    (c) draft-levy-megaco-mgdiscovery-01.txt
                  Thomas Levy (10 minutes)
    Contingency: 15 minutes

8. 10:56 Issues From The List
                  Tom Taylor (15 minutes)

9. 11:11 Re-Chartering discussion
                  Tom Taylor (15 minutes)

10. Interop
   Reference draft-rosen-megaco-test-profile-00.txt
   and draft-rosen-megaco-interop-1-report-00.txt
                  Brian Rosen (6 minutes)

Tom Taylor
taylor@nortelnetworks.com
Ph. +1 613 736 0961


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec  6 10:35:03 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00616
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Dec 2000 10:35:03 -0500 (EST)
Received: from standards (47.234.32.16:3914) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBFE47@standards.nortelnetworks.com>; Wed, 6 Dec 2000 10:15:39 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 162782 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Dec 2000 10:15:39 -0500
Received: from standards (47.234.32.16:3914) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBBFE46@standards.nortelnetworks.com>; Wed, 6 Dec 2000 10:15:39
          -0500
Message-ID:  <MEGACO%2000120610153940@STANDARDS.NORTELNETWORKS.COM>
Date:         Wed, 6 Dec 2000 10:15:39 -0500
Reply-To: Tom Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: RFC 3015 & Draft Megaco Agenda
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The basic equation is
RFC 2885 + RFC 2886 = H.248 (June 2000) = RFC 3015.

There seems to be some back and forth in our views of how the Implementor's Guide should be published.  I'm willing to create
either a brief I-D which just has a pointer to the IG on the ITU site, or else a full-fledged I-D reproducing the entire content.  There
is also the issue of officially approved vs. interim content; they should be documented separately so people know they are taking a
slight risk by acting on the interim material.  The obvious answer is to take the officially approved versions forward to RFC status.

Note that the ITU does not charge for Implementor's Guides.

As for H.248v2, it seems reasonable that people should want to discuss the possibilities on the list, and I can take responsibility for
feeding the material forward to SG 16.  Procedurally it would go in as an ISOC contribution if Scott agrees, or else as a Nortel
contribution.  I should remind people that ITU-T practice is to develop protocols incrementally.  That is, H.248v2 would not
normally deprecate any of the content of H.248v1, and H.248v1 and H.248v2 implementations should be able to interoperate.
Corrections documented in the Implementor's Guide would be assimilated into H.248v2.  One final point: absent pressing need,
ITU-T rules call for at least a two year gap between versions.  SG 16 hasn't let this rule get in the way of further development in
the past.

Tom Taylor


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec  6 11:33:38 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15036
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Dec 2000 11:33:37 -0500 (EST)
Received: from standards (47.234.32.16:3914) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBFED8@standards.nortelnetworks.com>; Wed, 6 Dec 2000 11:14:12 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 162969 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Dec 2000 11:14:12 -0500
Received: from radvpost.us.radvision.com (38.150.216.6:13219) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBFED7@standards.nortelnetworks.com>; Wed, 6 Dec 2000
          11:14:12 -0500
Received: by RADVPOST with Internet Mail Service (5.5.2650.21) id <YL2ZKYBW>;
          Wed, 6 Dec 2000 11:31: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:  <0D5BBF5D638DD4119E3400508BD9494524F857@RADVPOST>
Date:         Wed, 6 Dec 2000 11:31:24 -0500
Reply-To: Dan Elbert <DElbert@RADVISION.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Dan Elbert <DElbert@RADVISION.COM>
Subject:      Closing a stream in a termination
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

What should be the way of closing a specific stream in a termination, using
the Modify command ?
I guess that sending a stream descriptor (with the wanted stream id)
including an empty Local Descriptor will do it.
Is there any other way to achieve this ?

Thanks

Dan Elbert
Radvision


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec  6 12:17:39 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26145
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Dec 2000 12:17:38 -0500 (EST)
Received: from standards (47.234.32.16:3914) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBFF2B@standards.nortelnetworks.com>; Wed, 6 Dec 2000 11:58:26 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 163062 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Dec 2000 11:58:26 -0500
Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBBFF26@standards.nortelnetworks.com>; Wed, 6 Dec 2000 11:48:25
          -0500
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org
          (8.9.1a/8.9.1a) with ESMTP id MAA23590; Wed, 6 Dec 2000 12:05:59
          -0500 (EST)
Message-ID:  <200012061705.MAA23590@ietf.org>
Date:         Wed, 6 Dec 2000 12:05:59 -0500
Reply-To: The IESG <iesg-secretary@ietf.org>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
Comments:     RFC822 error: <W> CC field duplicated. Last occurrence was
              retained.
Comments:     RFC822 error: <W> CC field duplicated. Last occurrence was
              retained.
Comments:     RFC822 error: <W> Incorrect or incomplete address field found and
              ignored.
From: The IESG <iesg-secretary@ietf.org>
Subject:      Document Action: Megaco IP Phone Media Gateway Application
              Profile to Informational
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The IESG has approved the Internet-Draft 'Megaco IP Phone Media Gateway
Application Profile' <draft-ietf-megaco-ipphone-03.txt> as an
Informational RFC.  This document is the product of the Media Gateway
Control Working Group.  The IESG contact persons are Allison Mankin and
Scott Bradner.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec  6 13:03:30 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02684
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 6 Dec 2000 13:03:29 -0500 (EST)
Received: from standards (47.234.32.16:3914) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBBFF98@standards.nortelnetworks.com>; Wed, 6 Dec 2000 12:43:04 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 163172 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 6 Dec 2000 12:43:04 -0500
Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBBFF80@standards.nortelnetworks.com>; Wed, 6 Dec 2000
          12:33:04 -0500
Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by
          ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id MAA07578
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 6 Dec 2000 12:50:43
          -0500 (EST)
Received: from hotair.hobl.lucent.com (h199-118-135-2.lucent.com
          [199.118.135.2]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3)
          with SMTP id MAA07534; Wed, 6 Dec 2000 12:50:41 -0500 (EST)
Received: from nj7460gratta by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id
          MAA19443; Wed, 6 Dec 2000 12:50:36 -0500
MIME-Version: 1.0
Content-type: text/enriched; charset=ISO-8859-1
Content-transfer-encoding: Quoted-printable
Priority: normal
X-mailer: Pegasus Mail for Win32 (v3.01d)
Message-ID:  <200012061750.MAA19443@hotair.hobl.lucent.com>
Date:         Wed, 6 Dec 2000 12:50:02 -0500
Reply-To: gratta@lucent.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Greg Ratta <gratta@lucent.com>
Subject:      DEVELOPMENT OF CALL BEARER CONTROL PROTOCOL Q.CBC, BASED ON H.248
X-cc:         dick.rr.knight@bt.com, mdolly@att.com,
              Christian.Groves@ericsson.com, hiramatsu.yukio@lab.ntt.co.jp,
              arshey.odedra@itu.int, sob@harvard.edu, mankin@east.isi.edu
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: Quoted-printable

This message represents a communication to the IETF MEGACO
WG that was approved by ITU-T SG 11 at its December  6, 2000
meeting.<color><param>0100,0100,0100</param>


With this communication statement, we would like to inform you on
 the development by Study Group 11 of the Call Bearer Control
protocol, Q.1950.  Should you like to review the current draft,
please send an email request for the Acrobat PDF version of =91TD
PL/11-90=92 to Christian Groves <color><param>0000,0000,8000</param>{ HYPE=
RLINK
mailto:Christian.Groves@ericsson.com)
<color><param>0100,0100,0100</param>}(Christian.Groves@ericsson.com),  who=
 is active in your IETF
WG.  This activity is now approaching its  completion.  <color><param>0000=
,0000,0000</param>


The Call Bearer Control protocol specifies a =91vertical=92 interface
between a Call Control entity and a Bearer Control entity.  This
enables the offering of a full set of telephony (BICC) services,
independent of the underlying transport network.


The Call Bearer Control protocol has been based on the SG16
protocol H.248.  It uses the H.248 format, H.248 descriptors, H.248
 encoding, H.248 defined packages, etcetera.  Seven new H.248
packages have been defined.



Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protoc=
ols

Lucent Technologies
Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta@lucent.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec  7 05:50:59 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA26438
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 7 Dec 2000 05:50:58 -0500 (EST)
Received: from standards (47.234.32.16:1752) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0305@standards.nortelnetworks.com>; Thu, 7 Dec 2000 5:31:42 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 164366 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Dec 2000 05:31:42 -0500
Received: from smtp2.cluster.oleane.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBC0304@standards.nortelnetworks.com>; Thu, 7 Dec 2000 5:31:41
          -0500
Received: from oleane (dyn-1-1-002.Vin.dialup.oleane.fr [195.25.4.2]) by
          smtp2.cluster.oleane.net with SMTP id eB7AnLN42332 for
          <megaco@standards.nortelnetworks.com>; Thu, 7 Dec 2000 11:49:21 +0100
          (CET)
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_0015_01C06044.0D82EA60"
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:  <001801c0603b$ac01a5e0$8001a8c0@oleane.com>
Date:         Thu, 7 Dec 2000 11:51:36 +0100
Reply-To: Peter Lewis <peter.lewis@UPPERSIDE.FR>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Peter Lewis <peter.lewis@UPPERSIDE.FR>
Subject:      VoDSL Europe
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_0015_01C06044.0D82EA60
Content-Type: text/plain;
        charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

VoDSL Europe : the deployment scenario, Paris 16-19 January.
The international conference.
Visit the real first VoDSL exhibition ever organized:
http://www.upperside.fr/bavodsl2001.htm

------=_NextPart_000_0015_01C06044.0D82EA60
Content-Type: text/html;
        charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><FONT color=3D#000000 size=3D2><STRONG>VoDSL Europe </STRONG>: the =
deployment=20
scenario, Paris 16-19 January.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>The international =
conference.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>Visit the real first <STRONG>VoDSL =
exhibition=20
</STRONG>ever organized:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><A=20
href=3D"http://www.upperside.fr/bavodsl2001.htm">http://www.upperside.fr/=
bavodsl2001.htm</A></FONT></DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_0015_01C06044.0D82EA60--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec  7 10:39:36 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04866
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 7 Dec 2000 10:39:35 -0500 (EST)
Received: from standards (47.234.32.16:2203) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC048A@standards.nortelnetworks.com>; Thu, 7 Dec 2000 10:20:03 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 164846 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Dec 2000 10:20:02 -0500
Received: from standards (47.234.32.16:2203) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC0489@standards.nortelnetworks.com>; Thu, 7 Dec 2000 10:20:02
          -0500
Message-ID:  <MEGACO%2000120710200285@STANDARDS.NORTELNETWORKS.COM>
Date:         Thu, 7 Dec 2000 10:20:02 -0500
Reply-To: Tom Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Difference between InService and Test Termination States
X-To:         Kapil Nayar <knayar@HSS.HNS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

On Fri, 1 Dec 2000 15:34:19 +0530, Kapil Nayar <knayar@HSS.HNS.COM> wrote:

>Hi Tom,
>
>What is the difference between "INSERVICE" and "TEST" from the MG perspective ?
>Eg:
>Do we have a media only in "INSERVICE" or
>Do we allow an "ADD" only in "INSERVICE" etc.
>
>-Kapil Nayar
>Hughes Software Systems

When we were trying to nail down the intention of our service states, we had trouble assigning particular meanings to them.  I
suspect we could have made use of service models developed for other protocols, but we didn't.  I will also note that the existing
models tend to be multi-dimensional, reflecting both an equipment state (physical reality) and an administrative state
(restrictions
on use imposed through management action).  You can end up with at least a half dozen states, not just the three we've defined
in our protocol, if you consider the various possible combinations.

Anyway, you can't really assign an operational meaning to the "test" state in the MG which is different from "in-service".  The
intention is really that billable traffic should only be handled by an in-service termination (and even this statement may be too
strong).  In any event, only the MGC can know whether a given media flow is being enabled for test purposes or as part of a call.

Tom Taylor


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec  7 11:37:45 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14747
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 7 Dec 2000 11:37:44 -0500 (EST)
Received: from standards (47.234.32.16:2203) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0514@standards.nortelnetworks.com>; Thu, 7 Dec 2000 11:18:24 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 165025 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Dec 2000 11:18:24 -0500
Received: from radvpost.us.radvision.com (38.150.216.6:29560) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC0513@standards.nortelnetworks.com>; Thu, 7 Dec 2000
          11:18:24 -0500
Received: by RADVPOST with Internet Mail Service (5.5.2650.21) id <YNKZWZQ4>;
          Thu, 7 Dec 2000 11:35: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:  <0D5BBF5D638DD4119E3400508BD9494524F858@RADVPOST>
Date:         Thu, 7 Dec 2000 11:35:39 -0500
Reply-To: Dan Elbert <DElbert@RADVISION.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Dan Elbert <DElbert@RADVISION.COM>
Subject:      Error in example ? Add command response issue
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi
The spec specifies the behavior of the MG when reserving resources for a
media stream as:

  "If the value of a Reserve property is False, the MG SHALL choose one
   of the alternatives specified in the local descriptor (if present)
   and one of the alternatives specified in the remote descriptor (if
   present)...
   Finally, the MG shall send a reply to the MGC
   containing the alternatives for the local and/or remote descriptor that
it selected"

In the example given at the end of the spec, (pg.171-172, transaction 50003)
an ephemeral termination is created with both a Local and a Remote
descriptor, but only the Local descriptor is included in the Add response.
This may be trivial because there is only one option in the Remote
descriptor, but it doesn't seems to agree with the quote above. Is this an
error, or do we need some clarification in the spec? I think that in the
interop everybody followed the example and didn't returned the Remote
descriptor.

Thanks
Dan Elbert
RADVISION


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec  7 13:25:09 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07074
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 7 Dec 2000 13:25:09 -0500 (EST)
Received: from standards (47.234.32.16:4241) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0557@standards.nortelnetworks.com>; Thu, 7 Dec 2000 13:05:47 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 165104 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Dec 2000 13:05:47 -0500
Received: from standards (47.234.32.16:4241) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC0556@standards.nortelnetworks.com>; Thu, 7 Dec 2000 13:05:47
          -0500
Message-ID:  <MEGACO%2000120713054726@STANDARDS.NORTELNETWORKS.COM>
Date:         Thu, 7 Dec 2000 13:05:47 -0500
Reply-To: Tom Taylor <taylor@NORTELNETWORKS.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Tom Taylor <taylor@NORTELNETWORKS.COM>
Subject:      Re: Modification of event and sig parameter ASN.1 syntax
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Do I get the impression that the ASN.1 version of Megaco is only half-defined and you want to finish the job?  I'll remark that the
existence of both binary and text-encoded versions was deemed to be a major threat to interoperability at MGC 2000.  I suppose
it's way too late now to try to persuade people to stick to text implementations?

Tom Taylor


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec  7 13:42:30 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09239
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 7 Dec 2000 13:42:29 -0500 (EST)
Received: from standards (47.234.32.16:4241) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0582@standards.nortelnetworks.com>; Thu, 7 Dec 2000 13:23:14 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 165159 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Dec 2000 13:23:14 -0500
Received: from rtp-msg-core-1.cisco.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBC0581@standards.nortelnetworks.com>; Thu, 7 Dec 2000 13:23:14
          -0500
Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by
          rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA21074 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 7 Dec 2000 13:38:57 -0500
          (EST)
Received: from cisco.com (dhcp-128-107-134-156.cisco.com [128.107.134.156]) by
          mira-sjc5-1.cisco.com (Mirapoint) with ESMTP id ADE06648 (AUTH
          pmelanah); Thu, 7 Dec 2000 10:40:03 -0800 (PST)
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <MEGACO%2000120713054726@STANDARDS.NORTELNETWORKS.COM>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3A2FD917.F1979C40@cisco.com>
Date:         Thu, 7 Dec 2000 10:38:15 -0800
Reply-To: Paddu Melanahalli <pmelanah@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Paddu Melanahalli <pmelanah@CISCO.COM>
Organization: NSSU (Cisco's call agent "MGC" development Team),  Cisco Systems,
              Inc
Subject:      Difference matrix
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi,
does anybody arrived at a difference matrix for the new
Megaco RFC and ITU-T draft? If so pls share with us.
Thanks
Paddu
--
                Enthusiasm
You can do anything... if you have Enthusiasm.
Enthusiasm is the yeast makes your hopes rise to the stars.
Enthusiasm is the sparkle in your eyes.
Enthusiasm   with it there is accomplishment,
                       without it there are only alibis
________________________________________________________

Paddu Melanahalli,  Cisco Systems, NSSU
Voice:(408)525 5236 Fax: (408)527 1568  Pgr:(408)788 8275
Email: pmelanah@cisco.com
________________________________________________________


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec  7 13:55:00 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11477
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 7 Dec 2000 13:54:59 -0500 (EST)
Received: from standards (47.234.32.16:4241) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC05A1@standards.nortelnetworks.com>; Thu, 7 Dec 2000 13:35:49 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 165200 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Dec 2000 13:35:49 -0500
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC05A0@standards.nortelnetworks.com>; Thu, 7 Dec 2000 13:35:46
          -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id NAA06779; Thu, 7 Dec 2000 13:53:25 -0500 (EST)
Received: from stl-server-01.pit.comms.marconi.com
          (stl-server-01.pit.comms.marconi.com [169.144.36.27]) by
          mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA07518;
          Thu, 7 Dec 2000 13:53:27 -0500 (EST)
Received: by stl-server-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <YB6WWZ0Q>; Thu, 7 Dec 2000 13:53: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:  <4FBEA8857476D311A03300204840E1CF01A6EB49@whq-msgusr-02.pit.comms.marconi.com>
Date:         Thu, 7 Dec 2000 13:53:25 -0500
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: Difference matrix
X-To:         Paddu Melanahalli <pmelanah@CISCO.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This would not be possible, because there are no differences!!

Also, while you may be looking at an ITU-T "draft" the text is fully
determined&decided, and in the editor queue for publication.

Let me repeat:
        The text of RFC3015 and the text of Recommendation H.248 is
IDENTICAL
                except for boilerplate

The boilerplate is very small - first page is different, copyright is
different, definitions of MUST/SHALL/MAY... is different.  The formatting of
the document is different, so the headers & footers are different, and the
page
numbers are different -- but the section numbering is the same.  All the
rest is
the same.

Brian

> -----Original Message-----
> From: Paddu Melanahalli [mailto:pmelanah@CISCO.COM]
> Sent: Thursday, December 07, 2000 1:38 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Difference matrix
>
>
> Hi,
> does anybody arrived at a difference matrix for the new
> Megaco RFC and ITU-T draft? If so pls share with us.
> Thanks
> Paddu
> --
>                 Enthusiasm
> You can do anything... if you have Enthusiasm.
> Enthusiasm is the yeast makes your hopes rise to the stars.
> Enthusiasm is the sparkle in your eyes.
> Enthusiasm   with it there is accomplishment,
>                        without it there are only alibis
> ________________________________________________________
>
> Paddu Melanahalli,  Cisco Systems, NSSU
> Voice:(408)525 5236 Fax: (408)527 1568  Pgr:(408)788 8275
> Email: pmelanah@cisco.com
> ________________________________________________________
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec  7 14:29:37 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20463
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 7 Dec 2000 14:29:36 -0500 (EST)
Received: from standards (47.234.32.16:2892) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC05C3@standards.nortelnetworks.com>; Thu, 7 Dec 2000 14:09:49 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 165245 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Dec 2000 14:09:48 -0500
Received: from sj-msg-core-4.cisco.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBC05C2@standards.nortelnetworks.com>; Thu, 7 Dec 2000 14:09:48
          -0500
Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by
          sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id LAA11061; Thu, 7
          Dec 2000 11:27:29 -0800 (PST)
Received: from cisco.com (dhcp-128-107-134-156.cisco.com [128.107.134.156]) by
          mira-sjc5-1.cisco.com (Mirapoint) with ESMTP id ADE08064 (AUTH
          pmelanah); Thu, 7 Dec 2000 11:27:28 -0800 (PST)
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <4FBEA8857476D311A03300204840E1CF01A6EB49@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3A2FE434.3067E58C@cisco.com>
Date:         Thu, 7 Dec 2000 11:25:40 -0800
Reply-To: Paddu Melanahalli <pmelanah@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Paddu Melanahalli <pmelanah@CISCO.COM>
Organization: NSSU (Cisco's call agent "MGC" development Team),  Cisco Systems,
              Inc
Subject:      Re: Difference matrix
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hey Thanks,
How about this one  is there any difference between the IETF
draft and the IETF RFC ? If so where can I find the difference
matrix.
Thanks
Paddu
"Rosen, Brian" wrote:
>
> This would not be possible, because there are no differences!!
>
> Also, while you may be looking at an ITU-T "draft" the text is fully
> determined&decided, and in the editor queue for publication.
>
> Let me repeat:
>         The text of RFC3015 and the text of Recommendation H.248 is
> IDENTICAL
>                 except for boilerplate
>
> The boilerplate is very small - first page is different, copyright is
> different, definitions of MUST/SHALL/MAY... is different.  The formatting of
> the document is different, so the headers & footers are different, and the
> page
> numbers are different -- but the section numbering is the same.  All the
> rest is
> the same.
>
> Brian
>
> > -----Original Message-----
> > From: Paddu Melanahalli [mailto:pmelanah@CISCO.COM]
> > Sent: Thursday, December 07, 2000 1:38 PM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Difference matrix
> >
> >
> > Hi,
> > does anybody arrived at a difference matrix for the new
> > Megaco RFC and ITU-T draft? If so pls share with us.
> > Thanks
> > Paddu
> > --
> >                 Enthusiasm
> > You can do anything... if you have Enthusiasm.
> > Enthusiasm is the yeast makes your hopes rise to the stars.
> > Enthusiasm is the sparkle in your eyes.
> > Enthusiasm   with it there is accomplishment,
> >                        without it there are only alibis
> > ________________________________________________________
> >
> > Paddu Melanahalli,  Cisco Systems, NSSU
> > Voice:(408)525 5236 Fax: (408)527 1568  Pgr:(408)788 8275
> > Email: pmelanah@cisco.com
> > ________________________________________________________
> >

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

Paddu Melanahalli,  Cisco Systems, NSSU
Voice:(408)525 5236 Fax: (408)527 1568  Pgr:(408)788 8275
Email: pmelanah@cisco.com
________________________________________________________


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec  7 14:39:13 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22076
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 7 Dec 2000 14:39:12 -0500 (EST)
Received: from standards (47.234.32.16:2892) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC05DC@standards.nortelnetworks.com>; Thu, 7 Dec 2000 14:19:10 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 165278 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Dec 2000 14:19:10 -0500
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC05DB@standards.nortelnetworks.com>; Thu, 7 Dec 2000 14:19:09
          -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id OAA11893; Thu, 7 Dec 2000 14:36:49 -0500 (EST)
Received: from stl-server-01.pit.comms.marconi.com
          (stl-server-01.pit.comms.marconi.com [169.144.36.27]) by
          mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA20855;
          Thu, 7 Dec 2000 14:36:51 -0500 (EST)
Received: by stl-server-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <YB6WW8BW>; Thu, 7 Dec 2000 14:36:51 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF01A6EB4A@whq-msgusr-02.pit.comms.marconi.com>
Date:         Thu, 7 Dec 2000 14:36:50 -0500
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: Difference matrix
X-To:         Paddu Melanahalli <pmelanah@cisco.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Depends on which draft.  If you are looking at -merged-01, then there are
no substantive differences (abstract, contacts, things like that).
If you are looking at any version that is megaco-protocol-, then there are
differences.  Remember that 2885 was approval of a draft, which was then
modified by 2886 to result in 3015.  The EXACT changes are not necessarily
detailed completely in 2886, but EVERY item is fully discussed.  No changes
not detailed in 2886 were done in 3015, and since H.248 is the same as
3015, the same comments apply.

Brian

> -----Original Message-----
> From: Paddu Melanahalli [mailto:pmelanah@cisco.com]
> Sent: Thursday, December 07, 2000 2:26 PM
> To: Rosen, Brian
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Difference matrix
>
>
> Hey Thanks,
> How about this one  is there any difference between the IETF
> draft and the IETF RFC ? If so where can I find the difference
> matrix.
> Thanks
> Paddu
> "Rosen, Brian" wrote:
> >
> > This would not be possible, because there are no differences!!
> >
> > Also, while you may be looking at an ITU-T "draft" the text is fully
> > determined&decided, and in the editor queue for publication.
> >
> > Let me repeat:
> >         The text of RFC3015 and the text of Recommendation H.248 is
> > IDENTICAL
> >                 except for boilerplate
> >
> > The boilerplate is very small - first page is different,
> copyright is
> > different, definitions of MUST/SHALL/MAY... is different.
> The formatting of
> > the document is different, so the headers & footers are
> different, and the
> > page
> > numbers are different -- but the section numbering is the
> same.  All the
> > rest is
> > the same.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: Paddu Melanahalli [mailto:pmelanah@CISCO.COM]
> > > Sent: Thursday, December 07, 2000 1:38 PM
> > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Difference matrix
> > >
> > >
> > > Hi,
> > > does anybody arrived at a difference matrix for the new
> > > Megaco RFC and ITU-T draft? If so pls share with us.
> > > Thanks
> > > Paddu
> > > --
> > >                 Enthusiasm
> > > You can do anything... if you have Enthusiasm.
> > > Enthusiasm is the yeast makes your hopes rise to the stars.
> > > Enthusiasm is the sparkle in your eyes.
> > > Enthusiasm   with it there is accomplishment,
> > >                        without it there are only alibis
> > > ________________________________________________________
> > >
> > > Paddu Melanahalli,  Cisco Systems, NSSU
> > > Voice:(408)525 5236 Fax: (408)527 1568  Pgr:(408)788 8275
> > > Email: pmelanah@cisco.com
> > > ________________________________________________________
> > >
>
> --
>               Enthusiasm
> You can do anything... if you have Enthusiasm.
> Enthusiasm is the yeast makes your hopes rise to the stars.
> Enthusiasm is the sparkle in your eyes.
> Enthusiasm   with it there is accomplishment,
>                        without it there are only alibis
> ________________________________________________________
>
> Paddu Melanahalli,  Cisco Systems, NSSU
> Voice:(408)525 5236 Fax: (408)527 1568  Pgr:(408)788 8275
> Email: pmelanah@cisco.com
> ________________________________________________________
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec  7 15:21:39 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28013
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 7 Dec 2000 15:21:39 -0500 (EST)
Received: from standards (47.234.32.16:3402) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC061A@standards.nortelnetworks.com>; Thu, 7 Dec 2000 15:02:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 165348 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Dec 2000 15:02:23 -0500
Received: from netmail.alcatel.com (mail.alcatel.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC0614@standards.nortelnetworks.com>; Thu, 7 Dec 2000
          14:52:22 -0500
Received: from relay2.usa.alcatel.com (relay2.usa.alcatel.com [143.209.238.7])
          by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id OAA26796 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 7 Dec 2000 14:10:02 -0600
          (CST)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by
          relay2.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id OAA24127 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 7 Dec 2000 14:09:59 -0600
          (CST)
Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com
          [143.209.151.53]) by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP
          id eB7K94d02592 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 7 Dec
          2000 14:09:04 -0600 (CST)
Received: from usa.alcatel.com (localhost [127.0.0.1]) by
          sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id
          eB7K94019712 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 7 Dec
          2000 14:09:04 -0600 (CST)
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <MEGACO%2000120713054726@STANDARDS.NORTELNETWORKS.COM>
Content-Type: multipart/alternative;
              boundary="------------EF9BE6FC0EE8962C64C70A7B"
Message-ID:  <3A2FEE60.E2F22CC6@usa.alcatel.com>
Date:         Thu, 7 Dec 2000 14:09:04 -0600
Reply-To: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Subject:      Re: Modification of event and sig parameter ASN.1 syntax
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

Tom

Are you suggesting that for the interoperability testing we stick to just text implementations or
from now on all implementations of Megaco should be in text encoded?

Has anyone implemented an MGC that supports both text and binary?

Thanks
Chuong

Tom Taylor wrote:

> Do I get the impression that the ASN.1 version of Megaco is only half-defined and you want to finish the job?  I'll remark that the
> existence of both binary and text-encoded versions was deemed to be a major threat to interoperability at MGC 2000.  I suppose
> it's way too late now to try to persuade people to stick to text implementations?
>
> Tom Taylor




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



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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Tom
<p>Are you suggesting that for the interoperability testing we stick to
just text implementations or
<br>from now on all implementations of Megaco should be in text encoded?
<p>Has anyone implemented an MGC&nbsp;that supports both text and binary?
<p>Thanks
<br>Chuong
<p>Tom Taylor wrote:
<blockquote TYPE=CITE>Do I get the impression that the ASN.1 version of
Megaco is only half-defined and you want to finish the job?&nbsp; I'll
remark that the
<br>existence of both binary and text-encoded versions was deemed to be
a major threat to interoperability at MGC 2000.&nbsp; I suppose
<br>it's way too late now to try to persuade people to stick to text implementations?
<p>Tom Taylor</blockquote>

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

--------------EF9BE6FC0EE8962C64C70A7B--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec  7 15:30:01 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29978
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 7 Dec 2000 15:30:00 -0500 (EST)
Received: from standards (47.234.32.16:3402) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0637@standards.nortelnetworks.com>; Thu, 7 Dec 2000 15:10:39 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 165352 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Dec 2000 15:10:39 -0500
Received: from tnint06.telogy.com (mail.telogy.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC0617@standards.nortelnetworks.com>; Thu, 7 Dec 2000
          15:00:39 -0500
Received: by argentina.telogy.com with Internet Mail Service (5.5.2448.0) id
          <YHM5T10K>; Thu, 7 Dec 2000 15:18:13 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <61891BA043DED21180920090273F173801C7B0C2@argentina.telogy.com>
Date:         Thu, 7 Dec 2000 15:18:09 -0500
Reply-To: Panditha Govindaraj <pgovindaraj@TELOGY.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Panditha Govindaraj <pgovindaraj@TELOGY.COM>
Subject:      clarification in SDP parsing (octet string ) in Local descriptor
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi

        In the Example call flow of MEGACO RFC 2885

The local descriptor :

The local token follows by an octet string

This Octet string is the part of SDP grammar, In the SDP grammar

it is no where shown that the octet string can have a $ (does this mean
choose wild card) if yes how is this to be handled, as RFC 2327 for SDP

does not support the ($) & ( VAD=X-NNVAD ) operation , How is this suppose
to be handles in the SDP Parser of Megaco

Can somebody suggest me

Here is a copy of the Example



Local {
   v=0
   c=IN IP4 $
   m=audio $ RTP/AVP 4
   a=ptime:30
   v=0
   c=IN IP4 $
   m=audio $ RTP/AVP 0
a=fmtp:PCMU VAD=X-NNVAD
                     }

Thanks

Govindaraj.P


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec  7 16:09:31 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06051
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 7 Dec 2000 16:09:31 -0500 (EST)
Received: from standards (47.234.32.16:1172) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0654@standards.nortelnetworks.com>; Thu, 7 Dec 2000 15:50:17 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0033 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Dec 2000 15:50:17 -0500
Received: from auemail2.firewall.lucent.com (auemail2.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC0653@standards.nortelnetworks.com>; Thu, 7 Dec 2000
          15:50:16 -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 QAA01146
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 7 Dec 2000 16:07:59
          -0500 (EST)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by
          auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id QAA01125
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 7 Dec 2000 16:07:58
          -0500 (EST)
Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id QAA25624; Thu, 7 Dec
          2000 16:07:57 -0500
Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id
          QAA25617; Thu, 7 Dec 2000 16:07:56 -0500
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Original-CC: MEGACO@STANDARDS.NORTELNETWORKS.COM
References: <61891BA043DED21180920090273F173801C7B0C2@argentina.telogy.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3A2FFBDD.3AB6E3EC@lucent.com>
Date:         Thu, 7 Dec 2000 16:06:37 -0500
Reply-To: Troy Cauble <troy@bell-labs.com>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Troy Cauble <troy@LUCENT.COM>
Subject:      Re: clarification in SDP parsing (octet string ) in Local
              descriptor
X-To:         Panditha Govindaraj <pgovindaraj@TELOGY.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Seems to me that the octetString can have a $.
As for the SDP RFC, I guess they're bending the RFC.

   octetString          = *(nonEscapeChar)
   nonEscapeChar        = ( "\}" / %x01-7C / %x7E-FF )

-troy

Panditha Govindaraj wrote:
>
> Hi
>
>         In the Example call flow of MEGACO RFC 2885
>
> The local descriptor :
>
> The local token follows by an octet string
>
> This Octet string is the part of SDP grammar, In the SDP grammar
>
> it is no where shown that the octet string can have a $ (does this mean
> choose wild card) if yes how is this to be handled, as RFC 2327 for SDP
>
> does not support the ($) & ( VAD=X-NNVAD ) operation , How is this suppose
> to be handles in the SDP Parser of Megaco
>
> Can somebody suggest me
>
> Here is a copy of the Example
>
> Local {
>    v=0
>    c=IN IP4 $
>    m=audio $ RTP/AVP 4
>    a=ptime:30
>    v=0
>    c=IN IP4 $
>    m=audio $ RTP/AVP 0
> a=fmtp:PCMU VAD=X-NNVAD
>                      }
>
> Thanks
>
> Govindaraj.P


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec  7 16:56:43 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13931
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 7 Dec 2000 16:56:43 -0500 (EST)
Received: from standards (47.234.32.16:2584) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0674@standards.nortelnetworks.com>; Thu, 7 Dec 2000 16:37:30 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0075 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Dec 2000 16:37:30 -0500
Received: from slink12.ss7-link.com (mail.ss7-link.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC0673@standards.nortelnetworks.com>; Thu, 7 Dec 2000
          16:37:30 -0500
Received: by SLINK12 with Internet Mail Service (5.5.2650.21) id <YD67VCLW>;
          Thu, 7 Dec 2000 16:52:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <F1BD619B2A58D41197990050DA2C08E401D48B@SLINK12>
Date:         Thu, 7 Dec 2000 16:52:41 -0500
Reply-To: Dave Sclarsky <dsclarsky@SS7-LINK.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Dave Sclarsky <dsclarsky@SS7-LINK.COM>
Subject:      Event descriptors with ALL eventID in extended packages.
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi,

Per 7.1.9:
  "The ALL wildcard may be used for the EventID,
   indicating that all events from the specified
   package have to be detected."

Does this mean that an events descriptor that has
dd/* causes an MG to notify dd/std{tid=d0}, dd/d0
and dd/etd{tid=d0}, and possibly dd/ltd{tid=d0}?

Thanks,

============================
Dave Sclarsky
System Architect, Access Technology
S-Link Corporation
520 Fellowship Road, Suite C-304
Mt. Laurel, NJ 08054
dsclarsky@ss7-link.com
voice:856.642.9229x231 fax:856.642.0252
www.ss7-link.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec  7 17:05:31 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14986
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 7 Dec 2000 17:05:30 -0500 (EST)
Received: from standards (47.234.32.16:2584) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC068C@standards.nortelnetworks.com>; Thu, 7 Dec 2000 16:46:20 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0074 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Dec 2000 16:46:20 -0500
Received: from tnint06.telogy.com (mail.telogy.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC0672@standards.nortelnetworks.com>; Thu, 7 Dec 2000
          16:36:20 -0500
Received: by argentina.telogy.com with Internet Mail Service (5.5.2448.0) id
          <YHM5TFKJ>; Thu, 7 Dec 2000 16:53:55 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="windows-1252"
Message-ID:  <61891BA043DED21180920090273F173801C7B0C6@argentina.telogy.com>
Date:         Thu, 7 Dec 2000 16:53:52 -0500
Reply-To: Panditha Govindaraj <pgovindaraj@TELOGY.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Panditha Govindaraj <pgovindaraj@TELOGY.COM>
Subject:      Re: clarification in SDP parsing (octet string ) in Local descrip
              tor
X-To:         Troy Cauble <troy@bell-labs.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I understand that Octet string can have a $

but how do i parse this in SDP grammar, because i receive it as a part of
Octet string which has SDP grammar.

when it comes to MEGACO

Before i pass the Octet string to the SDP , How do i handle '$' in SDP as it
is a part of MEGACO

How is this to be handled.

Does this mean that RFC 2327 need to be updated.


Govind


-----Original Message-----
From: Troy Cauble [mailto:troy@lucent.com]
Sent: Thursday, December 07, 2000 4:07 PM
To: Panditha Govindaraj
Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: clarification in SDP parsing (octet string ) in Local
descriptor



Seems to me that the octetString can have a $.
As for the SDP RFC, I guess they're bending the RFC.

   octetString          = *(nonEscapeChar)
   nonEscapeChar        = ( "\}" / %x01-7C / %x7E-FF )

-troy

Panditha Govindaraj wrote:
>
> Hi
>
>         In the Example call flow of MEGACO RFC 2885
>
> The local descriptor :
>
> The local token follows by an octet string
>
> This Octet string is the part of SDP grammar, In the SDP grammar
>
> it is no where shown that the octet string can have a $ (does this mean
> choose wild card) if yes how is this to be handled, as RFC 2327 for SDP
>
> does not support the ($) & ( VAD=X-NNVAD ) operation , How is this suppose
> to be handles in the SDP Parser of Megaco
>
> Can somebody suggest me
>
> Here is a copy of the Example
>
> Local {
>    v=0
>    c=IN IP4 $
>    m=audio $ RTP/AVP 4
>    a=ptime:30
>    v=0
>    c=IN IP4 $
>    m=audio $ RTP/AVP 0
> a=fmtp:PCMU VAD=X-NNVAD
>                      }
>
> Thanks
>
> Govindaraj.P


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec  7 17:16:36 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17117
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 7 Dec 2000 17:16:35 -0500 (EST)
Received: from standards (47.234.32.16:2584) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC06A8@standards.nortelnetworks.com>; Thu, 7 Dec 2000 16:57:16 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0142 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Dec 2000 16:57:16 -0500
Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC06A7@standards.nortelnetworks.com>; Thu, 7 Dec 2000
          16:57:16 -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 RAA02028
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 7 Dec 2000 17:14:58
          -0500 (EST)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by
          hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id RAA02022
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 7 Dec 2000 17:14:58
          -0500 (EST)
Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id RAA26301; Thu, 7 Dec
          2000 17:14:56 -0500
Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id
          RAA26294; Thu, 7 Dec 2000 17:14:55 -0500
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Original-CC: MEGACO@STANDARDS.NORTELNETWORKS.COM
References: <MEGACO%2000120713054726@STANDARDS.NORTELNETWORKS.COM>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3A300B91.A0F2F993@lucent.com>
Date:         Thu, 7 Dec 2000 17:13:37 -0500
Reply-To: Troy Cauble <troy@bell-labs.com>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Troy Cauble <troy@LUCENT.COM>
Subject:      Re: Modification of event and sig parameter ASN.1 syntax
X-To:         Tom Taylor <taylor@NORTELNETWORKS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Tom Taylor wrote:
>
> Do I get the impression that the ASN.1 version of Megaco is only half-defined and you want to finish the job?  I'll remark that the
> existence of both binary and text-encoded versions was deemed to be a major threat to interoperability at MGC 2000.  I suppose
> it's way too late now to try to persuade people to stick to text implementations?
>
> Tom Taylor


Tom,

I'm not sure if this was directed at me, but what the hell...

I'd say it's more than "half-defined", but there are some noticeable
holes.  I would like the job to be finished, but I don't care who
does it.  (I just have to implement it.)  Richard Wu and I each made
some proposals that could be helpful earlier in this thread.

http://standards.nortelnetworks.com/scripts/wa.exe?A2=ind0012&L=megaco&F=&S=&P=409

If you want to be *really picky*, it's not fully specified in the
text encoding either.  Example: A VALUE (as part of a propertyParm
or eventOther, etc.) can be an Integer.  We know this from the
Package definition.  So how is the Integer encoded as a VALUE?
Are these all valid Integer encodings for VALUEs?

        9, 09, 17, F, 0F, 1F, 0xF, twenty-three

I'm looking for words like "decimal integer representation", or
"hexidecimal integer representation with a leading '0x'".

This issue and ASN.1 OCTET STRING issues similar to the one above
were brought up a month ago:

http://standards.nortelnetworks.com/scripts/wa.exe?A2=ind0011&L=megaco&O=A&P=6107


If "MGC 2000" refers to the February iterop, and if these issues
aren't clarified soon, binary interop will be ... interesting.

-troy


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec  7 18:01:36 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22840
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 7 Dec 2000 18:01:35 -0500 (EST)
Received: from standards (47.234.32.16:2409) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC06D9@standards.nortelnetworks.com>; Thu, 7 Dec 2000 17:42:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0207 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Dec 2000 17:42:23 -0500
Received: from zrchs148 (47.100.129.12:58371) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC06D6@standards.nortelnetworks.com>; Thu, 7 Dec 2000 17:32:21
          -0500
Received: from zrchb200.us.nortel.com (actually zrchb200) by zrchs148; Thu, 7
          Dec 2000 16:42:38 -0600
Received: from zrtpd00x.us.nortel.com ([47.140.202.32]) by
          zrchb200.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2652.39) id XNDSLPHM; Thu, 7 Dec 2000 16:49:58
          -0600
Received: from americasm01.nt.com (brtphe34.us.nortel.com [47.202.35.89]) by
          zrtpd00x.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2652.39) id YN94SMYY; Thu, 7 Dec 2000 17:49:56
          -0500
X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.10.20 9000/778)
X-Accept-Language: en
References: <3A2D2732.894B17D3@usa.alcatel.com>
MIME-version: 1.0
Content-type: text/html; charset="us-ascii"
Content-transfer-encoding: 7bit
Message-ID:  <3A301413.B386DBB4@americasm01.nt.com>
Date:         Thu, 7 Dec 2000 17:49:56 -0500
Reply-To: "Boyle, Kevin [NCRTP:3Z70:EXCH]" <kboyle@AMERICASM01.NT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Boyle, Kevin [NCRTP:3Z70:EXCH]" <kboyle@AMERICASM01.NT.COM>
Organization: Nortel Networks
Subject:      Re: [Fwd: ServiceChange corrections in Implementers Guide]
X-To:         Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body text="#000000" bgcolor="#FFFFFF" link="#0000FF" vlink="#FF0000" alink="#000088">
Comments inline below [KJBII]
<p>Kevin
<p>Chuong Nguyen wrote:
<blockquote TYPE=CITE>Ops.&nbsp; One more point in Section 11. last paragraph
<p>"The <b>MG</b> shall issue error 505 - Command Received before Restart
Response."
<br>The "MG" should be "MGC".
<br>&nbsp;</blockquote>
[KJBII] Actually, the text is correct.&nbsp; This error indicates that
the MG received a command from the MGC before it received the MGC's response
to the ServiceChange Restart.
<blockquote TYPE=CITE>&nbsp;
<br>This also brings up an interesting point.
<p>For sure error 505 applies to all commands before Restart but there
are exception for ServiceChange.
<p>For ServiceChange w/method Forced/Graceful, MGC should response w/error
505.
<br>For ServiceChange w/method HandOff or Failover, MGC should either accept
the
<br>registration or provide alternative MGC to try.
<p>Are the above assumption correct?
<br>&nbsp;</blockquote>
[KJBII] In these cases, the MG is in an active communication state with
the MGC, and then decides that it needs to go out of service.&nbsp; The
MGC may be in the process of sending a command while the MG is sending
the ServiceChange, and the commands "cross in the mail", so to speak.&nbsp;
In this case, the MG shouldn't reject the commands -- in fact, it should
continue to execute the commands if it can, until it recieves the MGC's
response to the Service Change, effectively taking the MG out of service.
<blockquote TYPE=CITE>&nbsp;
<br>Thanks
<br>Chuong
<p>Chuong Nguyen wrote:
<blockquote TYPE=CITE>Hi Christian
<p>I don't know if this was pointed out already.
<br>I am looking at H248_Implementors_guide_approved.zip.
<p>The change for Section 6.3&nbsp; Cold Start has the following:
<br>"If the MGC accepts the MG, it will send a Transaction Reply, with
the ServiceChangeMgcId
<br>set to itself."
<p>The change for Section 11.2 Cold Start has the following:
<br>"If the MGC accepts the MG's resignation, it sends a Transaction Reply
<b>not
</b>including
a
<br>ServiceChangeMgcId parameter."
<p>This 2 statements contradict each other.
<br>I think originally it was always "not" including a ServiceChangeMgcId
parameter.
<p>Also additional words might be added to clearly stated that
<br>"If the MG receives a Transaction Reply that includes a ServiceChangeMgcId
parameter, it sends
<br>a ServiceChange <b>w/a method of Restart </b>to the MGC specified in
the ServiceChangeMgcId."
<p>Otherwise someone might get confused and use ServiceChange w/a method
of handoff.
<p>Chuong
<pre>--&nbsp;
&nbsp; Alcatel USA, Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Internet: Chuong.Nguyen@usa.alcatel.com
&nbsp; 1000 Coit Road Plano, Texas 75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613
&nbsp; **** The opinions expressed are not those of Alcatel USA, Inc ****</pre>
&nbsp;</blockquote>

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

</body>
</html>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec  7 20:23:25 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA22975
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 7 Dec 2000 20:23:24 -0500 (EST)
Received: from standards (47.234.32.16:1368) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC079D@standards.nortelnetworks.com>; Thu, 7 Dec 2000 20:01:02 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 0463 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 7 Dec 2000 20:01:02 -0500
Received: from baucis.sc.intel.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBC079A@standards.nortelnetworks.com>; Thu, 7 Dec 2000 20:01:01
          -0500
Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by
          baucis.sc.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21
          19:27:27 smothers Exp $) with SMTP id BAA14621; Fri, 8 Dec 2000
          01:18:38 GMT
Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203
          (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 08 Dec 2000
          01:18:37 0000 (GMT)
Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2650.21) id
          <Y3W03BXL>; Thu, 7 Dec 2000 17:18:36 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <F1CE15E08172D4119247009027AE9D500194F090@FMSMSX37>
Date:         Thu, 7 Dec 2000 13:28:38 -0800
Reply-To: "Tulpule, Naren" <naren@TRILLIUM.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Tulpule, Naren" <naren@TRILLIUM.COM>
Subject:      Re: clarification in SDP parsing (octet string ) in Local descrip
              tor
X-To:         Troy Cauble <troy@bell-labs.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi Troy, Govinda and list,
  First, Govinda - IN IP4 $ is not in RFC2327 (SDP) as it is now, but very
likely will be added. You can take a look at the MMUSIC drafts - they're
recirculating the SDP RFC, plus adding ability to describe ATM parameters
(http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-atm-02.txt) among
others. I don't know which RFC or draft the a=fmtp line came from though -
it doesn't comply with RFCs 2733, 2833 or 2848. Good thing the Megaco spec
says it's only an example :-)
  Troy - I agree with you, they had absolutely no need to bend the SDP RFC.
They could have chosen to terminate SDP announcements with an invalid line
(e.g. "==" EOL). There are other improvements possible in the grammar of
course but perhaps it's too late now. Examples -
1. To know if a parmValue is a list-of-ANDed-values ("[ VALUE, VALUE, ...]")
or a range of values ("[ VALUE : VALUE]") you need to go past the first
VALUE when a prefix ("AND-" and "RANGE-") could have solved the problem
easily.
2. Ability to have comments embedded in the message seems really
superfluous. Is the MGC going to tell the MG "Keep up the good work" or
something :-) ? No Occam's razor was applied at any point in writing the
grammar.
3. There is a shift-reduce conflict when an MID is an MTP address, and
supposed to be followed by a SEP, because MTP address ends with a RBRKT
which ends with an LWSP. All parser builders would resolve it in favor of
shift but the grammar needs a reduce at this point.
    These are not unsurmountable difficulties of course, just unnecessary,
and contribute to complicate the pasring code in logic, code size and
runtime efficiency.

-- Naren.
These views and opinions are mine alone, not those of Intel    (yet ;-)
Narendra C. Tulpule SMTS, Trillium (an Intel company)
Ph: +1-310-442-9222              Fax: +1-310-442-1162
12100 Wilshire Bl #1800         Los Angeles, CA 90025


-----Original Message-----
From: Troy Cauble [mailto:troy@LUCENT.COM]
Sent: Thursday, December 07, 2000 1:07 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: clarification in SDP parsing (octet string ) in Local
descriptor


Seems to me that the octetString can have a $.
As for the SDP RFC, I guess they're bending the RFC.

   octetString          = *(nonEscapeChar)
   nonEscapeChar        = ( "\}" / %x01-7C / %x7E-FF )

-troy

Panditha Govindaraj wrote:
>
> Hi
>
>         In the Example call flow of MEGACO RFC 2885
>
> The local descriptor :
>
> The local token follows by an octet string
>
> This Octet string is the part of SDP grammar, In the SDP grammar
>
> it is no where shown that the octet string can have a $ (does this mean
> choose wild card) if yes how is this to be handled, as RFC 2327 for SDP
>
> does not support the ($) & ( VAD=X-NNVAD ) operation , How is this suppose
> to be handles in the SDP Parser of Megaco
>
> Can somebody suggest me
>
> Here is a copy of the Example
>
> Local {
>    v=0
>    c=IN IP4 $
>    m=audio $ RTP/AVP 4
>    a=ptime:30
>    v=0
>    c=IN IP4 $
>    m=audio $ RTP/AVP 0
> a=fmtp:PCMU VAD=X-NNVAD
>                      }
>
> Thanks
>
> Govindaraj.P


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec  8 06:13:42 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA25048
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Dec 2000 06:13:42 -0500 (EST)
Received: from standards (47.234.32.16:4758) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0AAD@standards.nortelnetworks.com>; Fri, 8 Dec 2000 5:54:21 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1528 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 05:54:21 -0500
Received: from hindon.hss.co.in (202.54.26.202:40615) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC0AAC@standards.nortelnetworks.com>; Fri, 8 Dec 2000 5:54:13
          -0500
Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in
          (8.10.0/8.10.0) with SMTP id eB8BDHJ16445 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 8 Dec 2000 16:43:18 +0530
          (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          652569AF.003C7156 ; Fri, 8 Dec 2000 16:30:11 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <652569AF.003C7086.00@sandesh.hss.hns.com>
Date:         Fri, 8 Dec 2000 16:36:09 +0530
Reply-To: chassija@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chanchal Hassija <chassija@HSS.HNS.COM>
Subject:      Implementor's Guide change
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hello,

It was agreed upon sometime back in the mailingList that

In the reply to Audit Capabilities, we need to send only list of statisticsIds
(and not value) in the statistics descriptor. But as per ABNF grammar, the value
is not optional in Statistics descriptor.

Have we included this change in Implementor's Guide ?

Thanks for your time
Chan.....


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec  8 08:37:14 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15219
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Dec 2000 08:37:13 -0500 (EST)
Received: from standards (47.234.32.16:3354) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0BF3@standards.nortelnetworks.com>; Fri, 8 Dec 2000 8:17:35 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 1958 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 08:17:35 -0500
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC0BF2@standards.nortelnetworks.com>; Fri, 8 Dec 2000 8:17:34
          -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id IAA29294; Fri, 8 Dec 2000 08:35:17 -0500 (EST)
Received: from stl-server-01.pit.comms.marconi.com
          (stl-server-01.pit.comms.marconi.com [169.144.36.27]) by
          mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA08228;
          Fri, 8 Dec 2000 08:35:19 -0500 (EST)
Received: by stl-server-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <YB6WX84L>; Fri, 8 Dec 2000 08:35:18 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF01A6EB56@whq-msgusr-02.pit.comms.marconi.com>
Date:         Fri, 8 Dec 2000 08:35:16 -0500
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: clarification in SDP parsing (octet string ) in Local descrip
              tor
X-To:         "Tulpule, Naren" <naren@TRILLIUM.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Naren

I am so sorry you were not contributing to the discussion when the grammar
was being solidified.  I am certain that all of us would have preferred that
the grammar used RANGE-d0,d6 rather than the difficult-to-parse d0:d6.
Prefix languages are fun.  I suppose you are a real lisp fan.  D'ja ever
try writing an APL parser?  That's pretty interesting.

I'm a little worried that we might have pushed back a little on getting
rid of comments.  Text based protocols being human readable, one often does
like
comments from time to time.  Turns out many real applications use fixed
hunks
of message text to accomplish tasks. Messages that humans write, and others
read.  'Course writing a parser for a text based grammar that includes
comments
might be considered difficult if only we hadn't gotten so used to them with
compilers and interpreters and just about everything else that uses a
parser,
right?

I like the suggestion I heard that you should have a runtime -verbose switch

which when on uses long tokens and leaves comments, when off uses short
tokens
and suppresses comments.

I actually would have tried to fix the shift-reduce issue.  That is
unnecessary,
but it's too late now.  We did fix several of these kinds of problems as we
developed the grammar.  There were 2-3 groups who were writing and modifying
parsers as the grammar evolved.  We made many edits as these brave souls
tried
to keep up with us and discovered ambiguities.  I believe the grammar can be

pretty easily fit into an LL(1) parser, and we have reports of several
others.
Lots of folks used yacc/lex which is LALR(1).

There were 12 or so DIFFERENT parsers at the first interop event.  No one
seemed
to have great difficulty with the grammar.  It's not a simple grammar, so
the
parsers aren't simple, but quite a few people have dealt with it.

Brian


> -----Original Message-----
> From: Tulpule, Naren [mailto:naren@TRILLIUM.COM]
> Sent: Thursday, December 07, 2000 4:29 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: clarification in SDP parsing (octet string ) in Local
> descrip tor
>
>
> Hi Troy, Govinda and list,
>   First, Govinda - IN IP4 $ is not in RFC2327 (SDP) as it is
> now, but very
> likely will be added. You can take a look at the MMUSIC
> drafts - they're
> recirculating the SDP RFC, plus adding ability to describe
> ATM parameters
> (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-atm
> -02.txt) among
> others. I don't know which RFC or draft the a=fmtp line came
> from though -
> it doesn't comply with RFCs 2733, 2833 or 2848. Good thing
> the Megaco spec
> says it's only an example :-)
>   Troy - I agree with you, they had absolutely no need to
> bend the SDP RFC.
> They could have chosen to terminate SDP announcements with an
> invalid line
> (e.g. "==" EOL). There are other improvements possible in the
> grammar of
> course but perhaps it's too late now. Examples -
> 1. To know if a parmValue is a list-of-ANDed-values ("[
> VALUE, VALUE, ...]")
> or a range of values ("[ VALUE : VALUE]") you need to go past
> the first
> VALUE when a prefix ("AND-" and "RANGE-") could have solved
> the problem
> easily.
> 2. Ability to have comments embedded in the message seems really
> superfluous. Is the MGC going to tell the MG "Keep up the
> good work" or
> something :-) ? No Occam's razor was applied at any point in
> writing the
> grammar.
> 3. There is a shift-reduce conflict when an MID is an MTP address, and
> supposed to be followed by a SEP, because MTP address ends
> with a RBRKT
> which ends with an LWSP. All parser builders would resolve it
> in favor of
> shift but the grammar needs a reduce at this point.
>     These are not unsurmountable difficulties of course, just
> unnecessary,
> and contribute to complicate the pasring code in logic, code size and
> runtime efficiency.
>
> -- Naren.
> These views and opinions are mine alone, not those of Intel
>  (yet ;-)
> Narendra C. Tulpule SMTS, Trillium (an Intel company)
> Ph: +1-310-442-9222              Fax: +1-310-442-1162
> 12100 Wilshire Bl #1800         Los Angeles, CA 90025
>
>
> -----Original Message-----
> From: Troy Cauble [mailto:troy@LUCENT.COM]
> Sent: Thursday, December 07, 2000 1:07 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: clarification in SDP parsing (octet string ) in Local
> descriptor
>
>
> Seems to me that the octetString can have a $.
> As for the SDP RFC, I guess they're bending the RFC.
>
>    octetString          = *(nonEscapeChar)
>    nonEscapeChar        = ( "\}" / %x01-7C / %x7E-FF )
>
> -troy
>
> Panditha Govindaraj wrote:
> >
> > Hi
> >
> >         In the Example call flow of MEGACO RFC 2885
> >
> > The local descriptor :
> >
> > The local token follows by an octet string
> >
> > This Octet string is the part of SDP grammar, In the SDP grammar
> >
> > it is no where shown that the octet string can have a $
> (does this mean
> > choose wild card) if yes how is this to be handled, as RFC
> 2327 for SDP
> >
> > does not support the ($) & ( VAD=X-NNVAD ) operation , How
> is this suppose
> > to be handles in the SDP Parser of Megaco
> >
> > Can somebody suggest me
> >
> > Here is a copy of the Example
> >
> > Local {
> >    v=0
> >    c=IN IP4 $
> >    m=audio $ RTP/AVP 4
> >    a=ptime:30
> >    v=0
> >    c=IN IP4 $
> >    m=audio $ RTP/AVP 0
> > a=fmtp:PCMU VAD=X-NNVAD
> >                      }
> >
> > Thanks
> >
> > Govindaraj.P
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec  8 09:22:10 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20430
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Dec 2000 09:22:09 -0500 (EST)
Received: from standards (47.234.32.16:3354) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0C38@standards.nortelnetworks.com>; Fri, 8 Dec 2000 9:02:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2033 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 09:02:23 -0500
Received: from netmail.alcatel.com (mail.alcatel.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC0C2B@standards.nortelnetworks.com>; Fri, 8 Dec 2000 8:52:23
          -0500
Received: from relay1.usa.alcatel.com (relay1.usa.alcatel.com [143.209.238.6])
          by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id IAA06136 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 8 Dec 2000 08:10:06 -0600
          (CST)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by
          relay1.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id IAA24601 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 8 Dec 2000 08:10:03 -0600
          (CST)
Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com
          [143.209.151.53]) by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP
          id eB8E9kd15064 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 8 Dec
          2000 08:09:46 -0600 (CST)
Received: from usa.alcatel.com (localhost [127.0.0.1]) by
          sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id
          eB8E9j022659 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 8 Dec
          2000 08:09:45 -0600 (CST)
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <3A2D2732.894B17D3@usa.alcatel.com>
            <3A301413.B386DBB4@americasm01.nt.com>
Content-Type: multipart/alternative;
              boundary="------------B1CA84C7D492D4AE9E32DC3E"
Message-ID:  <3A30EBA9.A3DCDB98@usa.alcatel.com>
Date:         Fri, 8 Dec 2000 08:09:45 -0600
Reply-To: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Subject:      Re: [Fwd: ServiceChange corrections in Implementers Guide]
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

Ok I miss read the thing.

I wanted to ask about Error code for MGC to send to MG if MG sends up
any command
before MG does a ServiceChange with Restart.

Said if MGC receives ServiceChange w/Forced/Graceful before receiving
ServiceChange
w/Restart from MG, what should the MGC do:

1) ignore the ServiceChange w/Forced/Graceful?
2) send a ServiceChange reply w/an Error code of ????

Thanks
Chuong

"Boyle, Kevin [NCRTP:3Z70:EXCH]" wrote:

> Comments inline below [KJBII]
>
> Kevin
>
> Chuong Nguyen wrote:
>
>> Ops.  One more point in Section 11. last paragraph
>>
>> "The MG shall issue error 505 - Command Received before Restart
>> Response."
>> The "MG" should be "MGC".
>>
>
> [KJBII] Actually, the text is correct.  This error indicates that the
> MG received a command from the MGC before it received the MGC's
> response to the ServiceChange Restart.

>
>
>>
>> This also brings up an interesting point.
>>
>> For sure error 505 applies to all commands before Restart but there
>> are exception for ServiceChange.
>>
>> For ServiceChange w/method Forced/Graceful, MGC should response
>> w/error 505.
>> For ServiceChange w/method HandOff or Failover, MGC should either
>> accept the
>> registration or provide alternative MGC to try.
>>
>> Are the above assumption correct?
>>
>
> [KJBII] In these cases, the MG is in an active communication state
> with the MGC, and then decides that it needs to go out of service.
> The MGC may be in the process of sending a command while the MG is
> sending the ServiceChange, and the commands "cross in the mail", so to
> speak.  In this case, the MG shouldn't reject the commands -- in fact,
> it should continue to execute the commands if it can, until it
> recieves the MGC's response to the Service Change, effectively taking
> the MG out of service.
>
>>
>> Thanks
>> Chuong
>>
>> Chuong Nguyen wrote:
>>
>> > Hi Christian
>> >
>> > I don't know if this was pointed out already.
>> > I am looking at H248_Implementors_guide_approved.zip.
>> >
>> > The change for Section 6.3  Cold Start has the following:
>> > "If the MGC accepts the MG, it will send a Transaction Reply, with
>> > the ServiceChangeMgcId
>> > set to itself."
>> >
>> > The change for Section 11.2 Cold Start has the following:
>> > "If the MGC accepts the MG's resignation, it sends a Transaction
>> > Reply not including a
>> > ServiceChangeMgcId parameter."
>> >
>> > This 2 statements contradict each other.
>> > I think originally it was always "not" including a
>> > ServiceChangeMgcId parameter.
>> >
>> > Also additional words might be added to clearly stated that
>> > "If the MG receives a Transaction Reply that includes a
>> > ServiceChangeMgcId parameter, it sends
>> > a ServiceChange w/a method of Restart to the MGC specified in the
>> > ServiceChangeMgcId."
>> >
>> > Otherwise someone might get confused and use ServiceChange w/a
>> > method of handoff.
>> >
>> > Chuong
>> >
>> > --
>> >   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>> >   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>> >   **** The opinions expressed are not those of Alcatel USA, Inc ****
>> >
>> >
>>
>> --
>>   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>>   **** The opinions expressed are not those of Alcatel USA, Inc ****
>>
>>
>
--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body text="#000000" bgcolor="#FFFFFF" link="#0000FF" vlink="#FF0000" alink="#000088">
Ok I&nbsp;miss read the thing.
<p>I&nbsp;wanted to ask about Error code for MGC&nbsp;to send to MG&nbsp;if
MG sends up any command
<br>before MG does a ServiceChange with Restart.
<p>Said if MGC receives ServiceChange w/Forced/Graceful before receiving
ServiceChange
<br>w/Restart from MG, what should the MGC&nbsp;do:
<p>1) ignore the ServiceChange w/Forced/Graceful?
<br>2) send a ServiceChange reply w/an Error code of ????
<p>Thanks
<br>Chuong
<p>"Boyle, Kevin [NCRTP:3Z70:EXCH]" wrote:
<blockquote TYPE=CITE>Comments inline below [KJBII]
<p>Kevin
<p>Chuong Nguyen wrote:
<blockquote TYPE=CITE>Ops.&nbsp; One more point in Section 11. last paragraph
<p>"The <b>MG</b> shall issue error 505 - Command Received before Restart
Response."
<br>The "MG" should be "MGC".
<br>&nbsp;</blockquote>
[KJBII] Actually, the text is correct.&nbsp; This error indicates that
the MG received a command from the MGC before it received the MGC's response
to the ServiceChange Restart.</blockquote>

<blockquote TYPE=CITE>&nbsp;
<blockquote TYPE=CITE>&nbsp;
<br>This also brings up an interesting point.
<p>For sure error 505 applies to all commands before Restart but there
are exception for ServiceChange.
<p>For ServiceChange w/method Forced/Graceful, MGC should response w/error
505.
<br>For ServiceChange w/method HandOff or Failover, MGC should either accept
the
<br>registration or provide alternative MGC to try.
<p>Are the above assumption correct?
<br>&nbsp;</blockquote>
[KJBII] In these cases, the MG is in an active communication state with
the MGC, and then decides that it needs to go out of service.&nbsp; The
MGC may be in the process of sending a command while the MG is sending
the ServiceChange, and the commands "cross in the mail", so to speak.&nbsp;
In this case, the MG shouldn't reject the commands -- in fact, it should
continue to execute the commands if it can, until it recieves the MGC's
response to the Service Change, effectively taking the MG out of service.
<blockquote TYPE=CITE>&nbsp;
<br>Thanks
<br>Chuong
<p>Chuong Nguyen wrote:
<blockquote TYPE=CITE>Hi Christian
<p>I don't know if this was pointed out already.
<br>I am looking at H248_Implementors_guide_approved.zip.
<p>The change for Section 6.3&nbsp; Cold Start has the following:
<br>"If the MGC accepts the MG, it will send a Transaction Reply, with
the ServiceChangeMgcId
<br>set to itself."
<p>The change for Section 11.2 Cold Start has the following:
<br>"If the MGC accepts the MG's resignation, it sends a Transaction Reply
<b>not
</b>including
a
<br>ServiceChangeMgcId parameter."
<p>This 2 statements contradict each other.
<br>I think originally it was always "not" including a ServiceChangeMgcId
parameter.
<p>Also additional words might be added to clearly stated that
<br>"If the MG receives a Transaction Reply that includes a ServiceChangeMgcId
parameter, it sends
<br>a ServiceChange <b>w/a method of Restart </b>to the MGC specified in
the ServiceChangeMgcId."
<p>Otherwise someone might get confused and use ServiceChange w/a method
of handoff.
<p>Chuong
<pre>--&nbsp;
&nbsp; Alcatel USA, Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Internet: Chuong.Nguyen@usa.alcatel.com
&nbsp; 1000 Coit Road Plano, Texas 75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613
&nbsp; **** The opinions expressed are not those of Alcatel USA, Inc ****</pre>
&nbsp;</blockquote>

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

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

--------------B1CA84C7D492D4AE9E32DC3E--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec  8 09:59:47 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24897
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Dec 2000 09:59:47 -0500 (EST)
Received: from standards (47.234.32.16:2817) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0C61@standards.nortelnetworks.com>; Fri, 8 Dec 2000 9:40:10 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2101 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 09:40:10 -0500
Received: from hindon.hss.co.in (202.54.26.202:45447) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC0C60@standards.nortelnetworks.com>; Fri, 8 Dec 2000 9:40:09
          -0500
Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in
          (8.10.0/8.10.0) with SMTP id eB8ExHI21395 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 8 Dec 2000 20:29:18 +0530
          (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          652569AF.005122BC ; Fri, 8 Dec 2000 20:16:13 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <652569AF.005121DC.00@sandesh.hss.hns.com>
Date:         Fri, 8 Dec 2000 20:22:10 +0530
Reply-To: chassija@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chanchal Hassija <chassija@HSS.HNS.COM>
Subject:      Package..Extension
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hello All,



Package B extends Package A



Package A : Event e1;

Package B : Event e2;



Both A and B are supported on a termination, T1



Can MGC tell MG to detect A/e2 on T1.



Thanks for your time

Chan....


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec  8 10:03:31 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25366
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Dec 2000 10:03:31 -0500 (EST)
Received: from standards (47.234.32.16:2817) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0C76@standards.nortelnetworks.com>; Fri, 8 Dec 2000 9:42:53 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2128 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 09:42:52 -0500
Received: from hindon.hss.co.in (202.54.26.202:45503) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC0C75@standards.nortelnetworks.com>; Fri, 8 Dec 2000 9:42:51
          -0500
Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in
          (8.10.0/8.10.0) with SMTP id eB8F20m21459 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 8 Dec 2000 20:32:00 +0530
          (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          652569AF.00515FBC ; Fri, 8 Dec 2000 20:18:49 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <652569AF.00515F14.00@sandesh.hss.hns.com>
Date:         Fri, 8 Dec 2000 20:24:47 +0530
Reply-To: samittal@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Sachin Mittal <samittal@HSS.HNS.COM>
Subject:      Default stream
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The default value of mode is inactive.
But mode is in LocalControl which is part of stream.
So is it true that a default stream exists on a physical termination ?


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec  8 10:51:10 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01035
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Dec 2000 10:51:05 -0500 (EST)
Received: from standards (47.234.32.16:2817) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0CB4@standards.nortelnetworks.com>; Fri, 8 Dec 2000 10:31:21 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2206 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 10:31:21 -0500
Received: from imr1.ericy.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBC0CB3@standards.nortelnetworks.com>; Fri, 8 Dec 2000 10:31:20
          -0500
Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by
          imr1.ericy.com (8.10.2/8.10.2) with ESMTP id eB8FkgL22106 for
          <megaco@standards.nortelnetworks.com>; Fri, 8 Dec 2000 09:47:42 -0600
          (CST)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
          by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id eB8FkgZ23334 for
          <megaco@standards.nortelnetworks.com>; Fri, 8 Dec 2000 09:46:42 -0600
          (CST)
Received: from b04d01.exu.ericsson.se (b04d01 [138.85.62.101]) by
          newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA21085 for
          <megaco@standards.nortelnetworks.com>; Fri, 8 Dec 2000 09:46:41 -0600
          (CST)
Received: (from eusdbd@localhost) by b04d01.exu.ericsson.se (8.9.1/8.9.1) id
          JAA05305 for megaco@standards.nortelnetworks.com; Fri, 8 Dec 2000
          09:46:13 -0600 (CST)
X-Sun-Charset: US-ASCII
Message-ID:  <200012081546.JAA05305@b04d01.exu.ericsson.se>
Date:         Fri, 8 Dec 2000 09:46:13 -0600
Reply-To: David Dykhuizen <eusdbd@EXU.ERICSSON.SE>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: David Dykhuizen <eusdbd@EXU.ERICSSON.SE>
Subject:      H.248 Mode Parameter
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hello:

Currently running into some issues with the "Mode" parameter
within H.248.  If we look at the interop report, full report
available at:

http://search.ietf.org/internet-drafts/draft-rosen-megaco-interop-1-report-00.tx

we see the following:

  4. Is it REQUIRED that the MGC send a media descriptor to a PHYSICAL
      termination in order to get media to flow?

      There are two questions actually:
      1) Is there a default state of MODE (text is silent)
      2) Should the MG demand a media descriptor before allowing media

      flow?

      Consensus is that:
      1) The default for MODE is Inactive
      2) MGCs should always send a media descriptor, with at least a
      MODE setting
      3) MGs should not depend on 2)


Was this issue ever followed up?  The report indicates there was a
"Consensus" that mode should be Inactive (note: would be nice to know
the reasons) but we don't have anything in the Implementors' Guide.


Thanks,
/David


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec  8 11:07:21 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03609
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Dec 2000 11:07:21 -0500 (EST)
Received: from standards (47.234.32.16:2817) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0CEB@standards.nortelnetworks.com>; Fri, 8 Dec 2000 10:47:54 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2278 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 10:47:54 -0500
Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC0CEA@standards.nortelnetworks.com>; Fri, 8 Dec 2000
          10:47:54 -0500
Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by
          ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id LAA05191
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 8 Dec 2000 11:05:39
          -0500 (EST)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by
          ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id LAA05175
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 8 Dec 2000 11:05:38
          -0500 (EST)
Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id LAA04747; Fri, 8 Dec
          2000 11:05:36 -0500
Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id
          LAA04744; Fri, 8 Dec 2000 11:05:35 -0500
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <F1CE15E08172D4119247009027AE9D500194F090@FMSMSX37>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3A310681.18942944@lucent.com>
Date:         Fri, 8 Dec 2000 11:04:17 -0500
Reply-To: Troy Cauble <troy@bell-labs.com>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Troy Cauble <troy@LUCENT.COM>
Subject:      Re: clarification in SDP parsing (octet string ) in Local
              descriptor
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Troy wrote:

>> As for the SDP RFC, I guess they're bending the RFC.


"Tulpule, Naren" wrote:

>   Troy - I agree with you, they had absolutely no need to bend the SDP RFC.
> They could have chosen to terminate SDP announcements with an invalid line
> (e.g. "==" EOL).


For the record, I want to point out that I wasn't complaining
about this.  (As I do about so many other things:)

-troy


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec  8 11:42:35 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10050
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Dec 2000 11:42:34 -0500 (EST)
Received: from standards (47.234.32.16:1117) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0D21@standards.nortelnetworks.com>; Fri, 8 Dec 2000 11:23:11 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2343 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 11:23:11 -0500
Received: from tnint06.telogy.com (mail.telogy.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC0D19@standards.nortelnetworks.com>; Fri, 8 Dec 2000
          11:13:11 -0500
Received: by argentina.telogy.com with Internet Mail Service (5.5.2448.0) id
          <YHM5THVK>; Fri, 8 Dec 2000 11:30:46 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <61891BA043DED21180920090273F173801C7B0D6@argentina.telogy.com>
Date:         Fri, 8 Dec 2000 11:30:45 -0500
Reply-To: Panditha Govindaraj <pgovindaraj@TELOGY.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Panditha Govindaraj <pgovindaraj@TELOGY.COM>
Subject:      Re: clarification in SDP parsing (octet string ) in Local descrip
              tor
X-To:         "Tulpule, Naren" <naren@TRILLIUM.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi Naren,Troy and list



Does this mean that i need to parse the Grammar in the
draft-ietf-mmusic-sdp-atm-02.txt
and not RFC 2327
and one more thing , How do I parse VAD=X-NNVAD and when does this occur,
Where is this defined in the grammar,

This indicates Voice activity Detection though it is in Example of MEgaco
Specs but
this is still valid. Can you help me to find a clarification on this.

As of now i have written a parser for the grammar in RFC 2327 which is SDP
,to parse the octet string in Local & Remote
Descriptors.
Do I need to parse the Remote descriptor using RFC 2327
and write a different parser for Local descriptor which parses the grammar
in
draft-ietf-mmusic-sdp-atm-02.txt
but still the VAD=X-NNVAD is not clarified

We have written our own parser , Where we parse each token

This was not mentioned the RFC 2885 right

Please clarify me , Expecting a reply soon.

Govind


-----Original Message-----
From: Tulpule, Naren [mailto:naren@TRILLIUM.COM]
Sent: Thursday, December 07, 2000 4:29 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: clarification in SDP parsing (octet string ) in Local
descrip tor


Hi Troy, Govinda and list,
  First, Govinda - IN IP4 $ is not in RFC2327 (SDP) as it is now, but very
likely will be added. You can take a look at the MMUSIC drafts - they're
recirculating the SDP RFC, plus adding ability to describe ATM parameters
(http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-atm-02.txt) among
others. I don't know which RFC or draft the a=fmtp line came from though -
it doesn't comply with RFCs 2733, 2833 or 2848. Good thing the Megaco spec
says it's only an example :-)
  Troy - I agree with you, they had absolutely no need to bend the SDP RFC.
They could have chosen to terminate SDP announcements with an invalid line
(e.g. "==" EOL). There are other improvements possible in the grammar of
course but perhaps it's too late now. Examples -
1. To know if a parmValue is a list-of-ANDed-values ("[ VALUE, VALUE, ...]")
or a range of values ("[ VALUE : VALUE]") you need to go past the first
VALUE when a prefix ("AND-" and "RANGE-") could have solved the problem
easily.
2. Ability to have comments embedded in the message seems really
superfluous. Is the MGC going to tell the MG "Keep up the good work" or
something :-) ? No Occam's razor was applied at any point in writing the
grammar.
3. There is a shift-reduce conflict when an MID is an MTP address, and
supposed to be followed by a SEP, because MTP address ends with a RBRKT
which ends with an LWSP. All parser builders would resolve it in favor of
shift but the grammar needs a reduce at this point.
    These are not unsurmountable difficulties of course, just unnecessary,
and contribute to complicate the pasring code in logic, code size and
runtime efficiency.

-- Naren.
These views and opinions are mine alone, not those of Intel    (yet ;-)
Narendra C. Tulpule SMTS, Trillium (an Intel company)
Ph: +1-310-442-9222              Fax: +1-310-442-1162
12100 Wilshire Bl #1800         Los Angeles, CA 90025


-----Original Message-----
From: Troy Cauble [mailto:troy@LUCENT.COM]
Sent: Thursday, December 07, 2000 1:07 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: clarification in SDP parsing (octet string ) in Local
descriptor


Seems to me that the octetString can have a $.
As for the SDP RFC, I guess they're bending the RFC.

   octetString          = *(nonEscapeChar)
   nonEscapeChar        = ( "\}" / %x01-7C / %x7E-FF )

-troy

Panditha Govindaraj wrote:
>
> Hi
>
>         In the Example call flow of MEGACO RFC 2885
>
> The local descriptor :
>
> The local token follows by an octet string
>
> This Octet string is the part of SDP grammar, In the SDP grammar
>
> it is no where shown that the octet string can have a $ (does this mean
> choose wild card) if yes how is this to be handled, as RFC 2327 for SDP
>
> does not support the ($) & ( VAD=X-NNVAD ) operation , How is this suppose
> to be handles in the SDP Parser of Megaco
>
> Can somebody suggest me
>
> Here is a copy of the Example
>
> Local {
>    v=0
>    c=IN IP4 $
>    m=audio $ RTP/AVP 4
>    a=ptime:30
>    v=0
>    c=IN IP4 $
>    m=audio $ RTP/AVP 0
> a=fmtp:PCMU VAD=X-NNVAD
>                      }
>
> Thanks
>
> Govindaraj.P


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec  8 12:00:01 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15035
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Dec 2000 12:00:01 -0500 (EST)
Received: from standards (47.234.32.16:1117) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0D47@standards.nortelnetworks.com>; Fri, 8 Dec 2000 11:40:14 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2391 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 11:40:14 -0500
Received: from zmers013 (47.124.1.40:38845) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC0D3E@standards.nortelnetworks.com>; Fri, 8 Dec 2000 11:30:13
          -0500
Received: from smtprch1.nortel.com (actually erchg0j) by zmers013; Fri, 8 Dec
          2000 11:35:14 -0500
Received: from zcard015.ca.nortel.com (actually zcard015) by
          smtprch1.nortel.com; Fri, 8 Dec 2000 10:32:35 -0600
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id
          <YMXD9FCJ>; Fri, 8 Dec 2000 11:32:28 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD110312A2CD@zcard00g.ca.nortel.com>
Date:         Fri, 8 Dec 2000 11:32:24 -0500
Reply-To: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Subject:      draft-ietf-megaco-fmtdeterm-00.txt
X-cc:         Roy Spitzer <rspitzer@telogy.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I propose to add draft-ietf-megaco-fmtdeterm-00.txt to the agenda under item
5 "Well-Aged Proposals".  Roy Spitzer will present (I think, else I will)
and is looking to take this forward to Informational.

Tom Taylor
+1 613 736 0961
taylor@nortelnetworks.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec  8 12:00:02 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15039
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Dec 2000 12:00:01 -0500 (EST)
Received: from standards (47.234.32.16:1117) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0D4C@standards.nortelnetworks.com>; Fri, 8 Dec 2000 11:40:15 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2392 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 11:40:15 -0500
Received: from zmers013 (47.124.1.40:38845) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC0D3F@standards.nortelnetworks.com>; Fri, 8 Dec 2000 11:30:14
          -0500
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by zmers013;
          Fri, 8 Dec 2000 11:40:07 -0500
Received: from zcard015.ca.nortel.com (actually zcard015) by
          ertpg14e1.nortelnetworks.com; Fri, 8 Dec 2000 11:39:07 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id
          <YMXD9FL2>; Fri, 8 Dec 2000 11:39:07 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD110312A2FC@zcard00g.ca.nortel.com>
Date:         Fri, 8 Dec 2000 11:39:06 -0500
Reply-To: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Subject:      Re: Conflicting packageIDs
X-To:         ssikri@HSS.HNS.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The packages have different numbers in the IANA registration page at
http://www.isi.edu/in-notes/iana/assignments/megaco-h248
Where did you get your numbers?

The R2 package got caught up in the general discussion on CAS, so there is
no package number yet.  I assume one of your Hughes colleagues is a member
of the CAS design team.

> -----Original Message-----
> From: Sachin Sikri [mailto:ssikri@HSS.HNS.COM]
> Sent: Wednesday, December 06, 2000 1:45 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: [MEGACO] Conflicting packageIDs
>
>
> Hi
>
>  Text Telephone package defined in Annex F and Keypad Package
> defined in Annnex
> G have conflicting package IDs as 0x0016.
> As per my thinking package ID for Text Telephone package
> should be 0x0010
> (Correct me if i am wrong).
> Also if anybody can tell me the package ID for R2 package.
>
> Regards
> Sachin Sikri
> Hughes Software System
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec  8 12:04:48 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16077
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Dec 2000 12:04:48 -0500 (EST)
Received: from standards (47.234.32.16:1117) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0D75@standards.nortelnetworks.com>; Fri, 8 Dec 2000 11:45:09 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2393 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 11:45:09 -0500
Received: from zmers013 (47.124.1.40:39758) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC0D40@standards.nortelnetworks.com>; Fri, 8 Dec 2000 11:35:09
          -0500
Received: from smtprch1.nortel.com (actually erchg0j) by zmers013; Fri, 8 Dec
          2000 11:51:40 -0500
Received: from zcard015.ca.nortel.com (actually zcard015) by
          smtprch1.nortel.com; Fri, 8 Dec 2000 10:51:30 -0600
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id
          <YMXD9FZR>; Fri, 8 Dec 2000 11:51:24 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD110312A338@zcard00g.ca.nortel.com>
Date:         Fri, 8 Dec 2000 11:51:16 -0500
Reply-To: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Subject:      Re: ServiceChange - Failover
X-To:         chassija@HSS.HNS.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

If the active MG can send out a ServiceChange message, it should do so.
This makes the MGC aware that the MG is being replaced.  The standby MG has
to initiate the new control association in any event, so it will (also)
issue a ServiceChange.

> -----Original Message-----
> From: Chanchal Hassija [mailto:chassija@HSS.HNS.COM]
> Sent: Wednesday, December 06, 2000 3:18 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: [MEGACO] ServiceChange - Failover
>
>
> Hello All,
>
>
>
>       The scenario is one MGC and two MGs...one active and
> one standby. On
>       faliure of active MG, standby MG is taking over.
>
>       It is the responsibility of which MG to send the
> ServiceChange (failover
>       method and MG impending failure as the reason). As per
> 11.4 section in the
>       protocol document, it appears that it is the
> responsibilityof the active
>       MG(MG which is going down). But if Active MG is not
> capable of sending a
>       message to MGC, how shall MGC come to know that the
> standby MG is now
>       active MG.
>
>       Is it not better that the MG which gets active after
> switchover sends the
>       ServiceChange ?
>
>
>
> Thanks for your time
>
> Chan...
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec  8 12:08:59 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16965
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Dec 2000 12:08:58 -0500 (EST)
Received: from standards (47.234.32.16:1117) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0D94@standards.nortelnetworks.com>; Fri, 8 Dec 2000 11:48:58 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2397 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 11:48:57 -0500
Received: from zmers013 (47.124.1.40:40549) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC0D43@standards.nortelnetworks.com>; Fri, 8 Dec 2000 11:38:57
          -0500
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by zmers013;
          Fri, 8 Dec 2000 11:56:27 -0500
Received: from zcard015.ca.nortel.com (actually zcard015) by
          ertpg14e1.nortelnetworks.com; Fri, 8 Dec 2000 11:56:07 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id
          <YMXD9F07>; Fri, 8 Dec 2000 11:56:07 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD110312A34D@zcard00g.ca.nortel.com>
Date:         Fri, 8 Dec 2000 11:55:58 -0500
Reply-To: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Subject:      Re: Error code for TermId not in Context
X-To:         kris_albert@lycos.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I would favour 430 Unknown TerminationID myself, on the grounds that it is
not known in the specified context.  Other opinions?

> -----Original Message-----
> From: Kris Albert [mailto:kris_albert@LYCOS.COM]
> Sent: Wednesday, December 06, 2000 8:32 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: [MEGACO] Error code for TermId not in Context
>
>
> Hi List!
> I have a query regarding the error code to be used when the
> specific termination id in a command request is not present
> in the context Id(specific/wildcarded) specified in the
> action request containing that command.
> My understanding is that it should use Error code 431- "No
> TerminationId matched a wildcard" for these error cases too.
> Am I right ? or should some other error code needs to be used
> or DEFINED?
>
> Thanks in advance,
> Kris
>
>
>
> Great Gift Idea!  FREE cell phone, internet ready at Lycos Marketplace
>  http://www.inphonic.lycos.com/redirect.asp?referringpage=www.lycosd1
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec  8 12:19:49 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19217
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Dec 2000 12:19:48 -0500 (EST)
Received: from standards (47.234.32.16:1117) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0DBE@standards.nortelnetworks.com>; Fri, 8 Dec 2000 12:00:27 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2518 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 12:00:27 -0500
Received: from zrchh190 (47.158.65.22:50640) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC0DA1@standards.nortelnetworks.com>; Fri, 8 Dec 2000 11:50:27
          -0500
Received: from smtprch1.nortel.com (actually erchg0j) by zrchh190; Fri, 8 Dec
          2000 11:08:27 -0600
Received: from zcard015.ca.nortel.com (actually zcard015) by
          smtprch1.nortel.com; Fri, 8 Dec 2000 11:07:14 -0600
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id
          <YMXD9GM3>; Fri, 8 Dec 2000 12:07:07 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
X-Orig: <taylor@nortelnetworks.com>
Message-ID:  <28560036253BD41191A10000F8BCBD110312A379@zcard00g.ca.nortel.com>
Date:         Fri, 8 Dec 2000 12:07:04 -0500
Reply-To: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Subject:      Re: DigMap Related Questions
X-To:         kris_albert@lycos.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi.

> -----Original Message-----
> From: Kris Albert [mailto:kris_albert@LYCOS.COM]
> Sent: Wednesday, December 06, 2000 12:17 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: [MEGACO] DigMap Related Questions
>
>
> Hi all,
>       I have few questions related to the digitmaps
>
>  1. What is the lifespan of a digitmap on a termination? Deos
> it have anything  to do with what context (Null/Non-Null)
> termination is in when the digit map  is defined fo the termination?

[PTT]
The basic rule for digit maps specified for an individual termination or a
group of terminations is that stated in the first paragraph of section
6.2.4:
<quote>
If not provisioned otherwise, all descriptors except TerminationState and
LocalControl default to empty/"no value" when a Termination is first created
or returned to the null Context.
</quote>
Provisioned digit maps persist for the life of the termination.  Digit maps
defined on ROOT persist until deleted.

>
>    2.  On the deletion of a ephemeral termination, Is it
> required to remove all  the digitmap definitions, which are
> associated with this termination.

[PTT]
Only if they were defined for this termination alone.

>
>  3. When a parmanent termination moves to NULL Context, will
> it retain all  the digitmap defined on it(when it was in the
> context), or will it retain
>  only the default(/provisioned) digitmap definitions(if any)
> on this  termination?

[PTT] See 1. above.

>
>  Are DigMaps defined while termId is in Null context treated
> as default values  which are restored when the termIf returns
> to NULL context.

[PTT] No, because of the rule quoted above.  The rule is perhaps too broad
and should have made more exceptions, but it's done now.
>
>
>
>  Thanks in advance,
>
>  kris
>
>
>
> Great Gift Idea!  FREE cell phone, internet ready at Lycos Marketplace
>  http://www.inphonic.lycos.com/redirect.asp?referringpage=www.lycosd1
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec  8 12:28:29 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21066
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Dec 2000 12:28:28 -0500 (EST)
Received: from standards (47.234.32.16:1117) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0DDD@standards.nortelnetworks.com>; Fri, 8 Dec 2000 12:09:04 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2551 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 12:09:04 -0500
Received: from zrchh190 (47.158.65.22:51629) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC0DBB@standards.nortelnetworks.com>; Fri, 8 Dec 2000 11:59:02
          -0500
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by zrchh190;
          Fri, 8 Dec 2000 11:15:02 -0600
Received: from zcard015.ca.nortel.com (actually zcard015) by
          ertpg14e1.nortelnetworks.com; Fri, 8 Dec 2000 12:13:58 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id
          <YMXD9GTX>; Fri, 8 Dec 2000 12:13:57 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
X-Orig: <taylor@nortelnetworks.com>
Message-ID:  <28560036253BD41191A10000F8BCBD110312A39F@zcard00g.ca.nortel.com>
Date:         Fri, 8 Dec 2000 12:13:56 -0500
Reply-To: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Subject:      Re: Closing a stream in a termination
X-To:         Dan Elbert <DElbert@RADVISION.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

If you just want to do it on a given termination, one possibility is as you
describe, another is to set the mode to "inactive" (if you expect to open it
again).  Section 7.1.6 has this to say about deleting a stream from an
entire context:
<quote>
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.
</quote>


> -----Original Message-----
> From: Dan Elbert [mailto:DElbert@RADVISION.COM]
> Sent: Wednesday, December 06, 2000 11:31 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: [MEGACO] Closing a stream in a termination
>
>
> What should be the way of closing a specific stream in a
> termination, using
> the Modify command ?
> I guess that sending a stream descriptor (with the wanted stream id)
> including an empty Local Descriptor will do it.
> Is there any other way to achieve this ?
>
> Thanks
>
> Dan Elbert
> Radvision
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec  8 12:32:58 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA22058
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Dec 2000 12:32:58 -0500 (EST)
Received: from standards (47.234.32.16:1117) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0DF6@standards.nortelnetworks.com>; Fri, 8 Dec 2000 12:13:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2583 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 12:13:23 -0500
Received: from zmers013 (47.124.1.40:44549) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC0DD3@standards.nortelnetworks.com>; Fri, 8 Dec 2000 12:03:23
          -0500
Received: from smtprch1.nortel.com (actually erchg0j) by zmers013; Fri, 8 Dec
          2000 12:20:46 -0500
Received: from zcard015.ca.nortel.com (actually zcard015) by
          smtprch1.nortel.com; Fri, 8 Dec 2000 11:20:36 -0600
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id
          <YMXD9G5F>; Fri, 8 Dec 2000 12:20:28 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD110312A3BA@zcard00g.ca.nortel.com>
Date:         Fri, 8 Dec 2000 12:20:22 -0500
Reply-To: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Subject:      Re: DEVELOPMENT OF CALL BEARER CONTROL PROTOCOL Q.CBC,
              B ASED ON H.248
X-To:         gratta@lucent.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Thanks for letting us know.  Would you like this added to the Megaco meeting
agenda for discussion?  I can present if you're not available (Christian
won't be there, he told me).

-----Original Message-----
From: Greg Ratta [mailto:gratta@LUCENT.COM]
Sent: Wednesday, December 06, 2000 12:50 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: [MEGACO] DEVELOPMENT OF CALL BEARER CONTROL PROTOCOL Q.CBC, BASED
ON H.248



This message represents a communication to the IETF MEGACO WG that was
approved by ITU-T SG 11 at its December 6, 2000 meeting.


With this communication statement, we would like to inform you on the
development by Study Group 11 of the Call Bearer Control protocol, Q.1950.
Should you like to review the current draft, please send an email request
for the Acrobat PDF version of 'TD PL/11-90' to Christian Groves { HYPERLINK
mailto:Christian.Groves@ericsson.com) }(Christian.Groves@ericsson.com), who
is active in your IETF WG. This activity is now approaching its completion.


The Call Bearer Control protocol specifies a 'vertical' interface between a
Call Control entity and a Bearer Control entity. This enables the offering
of a full set of telephony (BICC) services, independent of the underlying
transport network.


The Call Bearer Control protocol has been based on the SG16 protocol H.248.
It uses the H.248 format, H.248 descriptors, H.248 encoding, H.248 defined
packages, etcetera. Seven new H.248 packages have been defined.



Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and
protocols

Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196,
gratta@lucent.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec  8 13:22:11 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00193
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Dec 2000 13:22:06 -0500 (EST)
Received: from standards (47.234.32.16:1800) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0E3A@standards.nortelnetworks.com>; Fri, 8 Dec 2000 13:02:06 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2688 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 13:02:06 -0500
Received: from zmers013 (47.124.1.40:50925) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC0E26@standards.nortelnetworks.com>; Fri, 8 Dec 2000 12:52:06
          -0500
Received: from smtprch1.nortel.com (actually erchg0j) by zmers013; Fri, 8 Dec
          2000 13:08:03 -0500
Received: from zcard015.ca.nortel.com (actually zcard015) by
          smtprch1.nortel.com; Fri, 8 Dec 2000 12:07:53 -0600
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id
          <YMXD92J4>; Fri, 8 Dec 2000 13:07:46 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD110312A49E@zcard00g.ca.nortel.com>
Date:         Fri, 8 Dec 2000 13:07:37 -0500
Reply-To: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Subject:      Re: Modification of event and sig parameter ASN.1 syntax
X-To:         Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

MGC 2000 was a conference I attended last month.  What I was saying was that
by specifying two different encodings we have in effect created two
different protocols: MGCs of one persuasion won't talk to MGs of the other.
It's unfair of me to try to turn the clock back, but the scarcity of
binary-encoded implementations up to now gave me the very faint hope that
those wanting to do binary could be persuaded to do text instead.

-----Original Message-----
From: Chuong Nguyen [mailto:Chuong.Nguyen@USA.ALCATEL.COM]
Sent: Thursday, December 07, 2000 3:09 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: [MEGACO] Modification of event and sig parameter ASN.1 syntax


Tom

Are you suggesting that for the interoperability testing we stick to just
text implementations or
from now on all implementations of Megaco should be in text encoded?


Has anyone implemented an MGC that supports both text and binary?


Thanks
Chuong


Tom Taylor wrote:


Do I get the impression that the ASN.1 version of Megaco is only
half-defined and you want to finish the job?  I'll remark that the
existence of both binary and text-encoded versions was deemed to be a major
threat to interoperability at MGC 2000.  I suppose
it's way too late now to try to persuade people to stick to text
implementations?

Tom Taylor




--

  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com

  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613

  **** The opinions expressed are not those of Alcatel USA, Inc ****


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec  8 13:27:52 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA00903
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Dec 2000 13:27:51 -0500 (EST)
Received: from standards (47.234.32.16:1800) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0E5F@standards.nortelnetworks.com>; Fri, 8 Dec 2000 13:08:33 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2691 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 13:08:33 -0500
Received: from zmers013 (47.124.1.40:51976) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC0E29@standards.nortelnetworks.com>; Fri, 8 Dec 2000 12:58:33
          -0500
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by zmers013;
          Fri, 8 Dec 2000 13:14:29 -0500
Received: from zcard015.ca.nortel.com (actually zcard015) by
          ertpg14e1.nortelnetworks.com; Fri, 8 Dec 2000 13:11:24 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id
          <YMXD923J>; Fri, 8 Dec 2000 13:11:24 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD110312A4AE@zcard00g.ca.nortel.com>
Date:         Fri, 8 Dec 2000 13:11:17 -0500
Reply-To: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Subject:      Re: Event descriptors with ALL eventID in extended packa ges.
X-To:         Dave Sclarsky <dsclarsky@SS7-LINK.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I'm afraid so.  That package is too big!

> -----Original Message-----
> From: Dave Sclarsky [mailto:dsclarsky@SS7-LINK.COM]
> Sent: Thursday, December 07, 2000 4:53 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: [MEGACO] Event descriptors with ALL eventID in extended
> packages.
>
>
> Hi,
>
> Per 7.1.9:
>   "The ALL wildcard may be used for the EventID,
>    indicating that all events from the specified
>    package have to be detected."
>
> Does this mean that an events descriptor that has
> dd/* causes an MG to notify dd/std{tid=d0}, dd/d0
> and dd/etd{tid=d0}, and possibly dd/ltd{tid=d0}?
>
> Thanks,
>
> ============================
> Dave Sclarsky
> System Architect, Access Technology
> S-Link Corporation
> 520 Fellowship Road, Suite C-304
> Mt. Laurel, NJ 08054
> dsclarsky@ss7-link.com
> voice:856.642.9229x231 fax:856.642.0252
> www.ss7-link.com
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec  8 13:32:00 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01368
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Dec 2000 13:31:59 -0500 (EST)
Received: from standards (47.234.32.16:1800) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0E6E@standards.nortelnetworks.com>; Fri, 8 Dec 2000 13:10:41 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2702 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 13:10:40 -0500
Received: from zrchh190 (47.158.65.22:56566) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC0E30@standards.nortelnetworks.com>; Fri, 8 Dec 2000 13:00:40
          -0500
Received: from smtprch1.nortel.com (actually erchg0j) by zrchh190; Fri, 8 Dec
          2000 12:16:32 -0600
Received: from zcard015.ca.nortel.com (actually zcard015) by
          smtprch1.nortel.com; Fri, 8 Dec 2000 12:15:30 -0600
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id
          <YMXD92SW>; Fri, 8 Dec 2000 13:15:23 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
X-Orig: <taylor@nortelnetworks.com>
Message-ID:  <28560036253BD41191A10000F8BCBD110312A4C8@zcard00g.ca.nortel.com>
Date:         Fri, 8 Dec 2000 13:15:18 -0500
Reply-To: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Subject:      Re: Package..Extension
X-To:         chassija@HSS.HNS.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

No, you can request B/e1 but not A/e2.

> -----Original Message-----
> From: Chanchal Hassija [mailto:chassija@HSS.HNS.COM]
> Sent: Friday, December 08, 2000 9:52 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: [MEGACO] Package..Extension
>
>
> Hello All,
>
>
>
> Package B extends Package A
>
>
>
> Package A : Event e1;
>
> Package B : Event e2;
>
>
>
> Both A and B are supported on a termination, T1
>
>
>
> Can MGC tell MG to detect A/e2 on T1.
>
>
>
> Thanks for your time
>
> Chan....
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec  8 13:32:00 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01371
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Dec 2000 13:32:00 -0500 (EST)
Received: from standards (47.234.32.16:1800) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0E7F@standards.nortelnetworks.com>; Fri, 8 Dec 2000 13:12:25 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2718 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 13:12:24 -0500
Received: from zmers013 (47.124.1.40:52403) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC0E41@standards.nortelnetworks.com>; Fri, 8 Dec 2000 13:02:23
          -0500
Received: from smtprch1.nortel.com (actually erchg0j) by zmers013; Fri, 8 Dec
          2000 13:19:55 -0500
Received: from zcard015.ca.nortel.com (actually zcard015) by
          smtprch1.nortel.com; Fri, 8 Dec 2000 12:19:51 -0600
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id
          <YMXD92XX>; Fri, 8 Dec 2000 13:19:45 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
Message-ID:  <28560036253BD41191A10000F8BCBD110312A4DE@zcard00g.ca.nortel.com>
Date:         Fri, 8 Dec 2000 13:19:32 -0500
Reply-To: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Subject:      Re: Default stream
X-To:         samittal@HSS.HNS.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

You can answer the question two ways, and I'm not sure it makes any
difference.  The first way is to say that IF you instantiate ANY stream the
mode (if unspecified) is inactive.  That is certainly true.  In addition,
you could say that stream 1 is a default on any termination.

> -----Original Message-----
> From: Sachin Mittal [mailto:samittal@HSS.HNS.COM]
> Sent: Friday, December 08, 2000 9:55 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: [MEGACO] Default stream
>
>
> The default value of mode is inactive.
> But mode is in LocalControl which is part of stream.
> So is it true that a default stream exists on a physical termination ?
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec  8 13:36:18 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01951
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Dec 2000 13:36:17 -0500 (EST)
Received: from standards (47.234.32.16:1800) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0EB9@standards.nortelnetworks.com>; Fri, 8 Dec 2000 13:15:55 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2739 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 13:15:55 -0500
Received: from zrchh190 (47.158.65.22:57064) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC0E50@standards.nortelnetworks.com>; Fri, 8 Dec 2000 13:05:55
          -0500
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by zrchh190;
          Fri, 8 Dec 2000 12:24:12 -0600
Received: from zcard015.ca.nortel.com (actually zcard015) by
          ertpg14e1.nortelnetworks.com; Fri, 8 Dec 2000 13:23:13 -0500
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id
          <YMXD926S>; Fri, 8 Dec 2000 13:23:13 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
X-Orig: <taylor@nortelnetworks.com>
Message-ID:  <28560036253BD41191A10000F8BCBD110312A4F0@zcard00g.ca.nortel.com>
Date:         Fri, 8 Dec 2000 13:23:09 -0500
Reply-To: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Subject:      Re: H.248 Mode Parameter
X-To:         David Dykhuizen <eusdbd@EXU.ERICSSON.SE>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I vaguely recall discussion of default mode half a year to a year ago.
(Getting old -- used to be I could locate the reference.)  May I confirm the
consensus as stated on the list?  Then we can see about getting it added to
the IG.

> -----Original Message-----
> From: David Dykhuizen [mailto:eusdbd@EXU.ERICSSON.SE]
> Sent: Friday, December 08, 2000 10:46 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: [MEGACO] H.248 Mode Parameter
>
>
> Hello:
>
> Currently running into some issues with the "Mode" parameter
> within H.248.  If we look at the interop report, full report
> available at:
>
> http://search.ietf.org/internet-drafts/draft-rosen-megaco-inte
> rop-1-report-00.tx
>
> we see the following:
>
>   4. Is it REQUIRED that the MGC send a media descriptor to a PHYSICAL
>       termination in order to get media to flow?
>
>       There are two questions actually:
>       1) Is there a default state of MODE (text is silent)
>       2) Should the MG demand a media descriptor before allowing media
>
>       flow?
>
>       Consensus is that:
>       1) The default for MODE is Inactive
>       2) MGCs should always send a media descriptor, with at least a
>       MODE setting
>       3) MGs should not depend on 2)
>
>
> Was this issue ever followed up?  The report indicates there was a
> "Consensus" that mode should be Inactive (note: would be nice to know
> the reasons) but we don't have anything in the Implementors' Guide.
>
>
> Thanks,
> /David
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec  8 14:02:41 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09884
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Dec 2000 14:02:41 -0500 (EST)
Received: from standards (47.234.32.16:1800) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0EF7@standards.nortelnetworks.com>; Fri, 8 Dec 2000 13:43:21 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 2951 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 13:43:21 -0500
Received: from zmers013 (47.124.1.40:56742) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC0EF2@standards.nortelnetworks.com>; Fri, 8 Dec 2000 13:33:21
          -0500
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by zmers013;
          Fri, 8 Dec 2000 13:50:20 -0500
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Fri, 8 Dec 2000 13:50:00 -0500
Received: from zrtpd00x.us.nortel.com ([47.140.202.32]) by
          zrtpd004.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2652.39) id YMLK6ZTP; Fri, 8 Dec 2000 13:50:00
          -0500
Received: from americasm01.nt.com (brtphe34.us.nortel.com [47.202.35.89]) by
          zrtpd00x.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2652.39) id YN94SQZW; Fri, 8 Dec 2000 13:49:58
          -0500
X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.10.20 9000/778)
X-Accept-Language: en
MIME-Version: 1.0
References: <3A2D2732.894B17D3@usa.alcatel.com>
            <3A301413.B386DBB4@americasm01.nt.com>
            <3A30EBA9.A3DCDB98@usa.alcatel.com>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3A312D56.E2954351@americasm01.nt.com>
Date:         Fri, 8 Dec 2000 13:49:58 -0500
Reply-To: "Boyle, Kevin [NCRTP:3Z70:EXCH]" <kboyle@AMERICASM01.NT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Boyle, Kevin [NCRTP:3Z70:EXCH]" <kboyle@AMERICASM01.NT.COM>
Organization: Nortel Networks
Subject:      Re: [Fwd: ServiceChange corrections in Implementers Guide]
X-To:         Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body text="#000000" bgcolor="#FFFFFF" link="#0000FF" vlink="#FF0000" alink="#000088">
I would say that the MGC will process them like any other communication
from the MG: in the order of receipt.&nbsp; That is, the MGC will finish
processing the Restart, and then process the Forced/Graceful appropriately.
<p>Kevin
<p>Chuong Nguyen wrote:
<blockquote TYPE=CITE>Ok I miss read the thing.
<p>I wanted to ask about Error code for MGC to send to MG if MG sends up
any command
<br>before MG does a ServiceChange with Restart.
<p>Said if MGC receives ServiceChange w/Forced/Graceful before receiving
ServiceChange
<br>w/Restart from MG, what should the MGC do:
<p>1) ignore the ServiceChange w/Forced/Graceful?
<br>2) send a ServiceChange reply w/an Error code of ????
<p>Thanks
<br>Chuong
<p>"Boyle, Kevin [NCRTP:3Z70:EXCH]" wrote:
<blockquote TYPE=CITE>Comments inline below [KJBII]
<p>Kevin
<p>Chuong Nguyen wrote:
<blockquote TYPE=CITE>Ops.&nbsp; One more point in Section 11. last paragraph
<p>"The <b>MG</b> shall issue error 505 - Command Received before Restart
Response."
<br>The "MG" should be "MGC".
<br>&nbsp;</blockquote>
[KJBII] Actually, the text is correct.&nbsp; This error indicates that
the MG received a command from the MGC before it received the MGC's response
to the ServiceChange Restart.</blockquote>

<blockquote TYPE=CITE>&nbsp;
<blockquote TYPE=CITE>&nbsp;
<br>This also brings up an interesting point.
<p>For sure error 505 applies to all commands before Restart but there
are exception for ServiceChange.
<p>For ServiceChange w/method Forced/Graceful, MGC should response w/error
505.
<br>For ServiceChange w/method HandOff or Failover, MGC should either accept
the
<br>registration or provide alternative MGC to try.
<p>Are the above assumption correct?
<br>&nbsp;</blockquote>
[KJBII] In these cases, the MG is in an active communication state with
the MGC, and then decides that it needs to go out of service.&nbsp; The
MGC may be in the process of sending a command while the MG is sending
the ServiceChange, and the commands "cross in the mail", so to speak.&nbsp;
In this case, the MG shouldn't reject the commands -- in fact, it should
continue to execute the commands if it can, until it recieves the MGC's
response to the Service Change, effectively taking the MG out of service.
<blockquote TYPE=CITE>&nbsp;
<br>Thanks
<br>Chuong
<p>Chuong Nguyen wrote:
<blockquote TYPE=CITE>Hi Christian
<p>I don't know if this was pointed out already.
<br>I am looking at H248_Implementors_guide_approved.zip.
<p>The change for Section 6.3&nbsp; Cold Start has the following:
<br>"If the MGC accepts the MG, it will send a Transaction Reply, with
the ServiceChangeMgcId
<br>set to itself."
<p>The change for Section 11.2 Cold Start has the following:
<br>"If the MGC accepts the MG's resignation, it sends a Transaction Reply
<b>not
</b>including
a
<br>ServiceChangeMgcId parameter."
<p>This 2 statements contradict each other.
<br>I think originally it was always "not" including a ServiceChangeMgcId
parameter.
<p>Also additional words might be added to clearly stated that
<br>"If the MG receives a Transaction Reply that includes a ServiceChangeMgcId
parameter, it sends
<br>a ServiceChange <b>w/a method of Restart </b>to the MGC specified in
the ServiceChangeMgcId."
<p>Otherwise someone might get confused and use ServiceChange w/a method
of handoff.
<p>Chuong</blockquote>
</blockquote>
</blockquote>

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

</body>
</html>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec  8 14:51:15 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28170
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Dec 2000 14:51:14 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0F1E@standards.nortelnetworks.com>; Fri, 8 Dec 2000 14:31:44 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3008 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 14:31:44 -0500
Received: from thalia.fm.intel.com (132.233.247.11:2789) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC0F1D@standards.nortelnetworks.com>; Fri, 8 Dec 2000
          14:31:43 -0500
Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by
          thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21
          19:27:27 smothers Exp $) with SMTP id TAA23523; Fri, 8 Dec 2000
          19:50:26 GMT
Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.204
          (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 08 Dec 2000
          19:49:06 0000 (GMT)
Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2650.21) id
          <YD6PD6K3>; Fri, 8 Dec 2000 11:48:50 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <F1CE15E08172D4119247009027AE9D500194F095@FMSMSX37>
Date:         Fri, 8 Dec 2000 11:48:50 -0800
Reply-To: "Tulpule, Naren" <naren@TRILLIUM.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Tulpule, Naren" <naren@TRILLIUM.COM>
Subject:      Re: clarification in SDP parsing (octet string ) in Local descrip
              tor
X-To:         "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi Brian and list,
  My apologies to Troy, I was whinging about the grammar, he was NOT.
Brian,
   I will not harp on this lest this generates into a pointless flamewar
(started by me!!) I was pointing out what I thought were unnecessary
features. I am not convinced about the SDP format changes but as to the
rest, yes they're overcome using a parser-builder. I have to implement it
anyway, but don't call me a LISP fan :-)

-- Naren.
These views and opinions are mine alone, not those of Intel    (yet ;-)
Narendra C. Tulpule SMTS, Trillium (an Intel company)
Ph: +1-310-442-9222              Fax: +1-310-442-1162
12100 Wilshire Bl #1800         Los Angeles, CA 90025


-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
Sent: Friday, December 08, 2000 5:35 AM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: clarification in SDP parsing (octet string ) in Local
descrip tor


Naren

I am so sorry you were not contributing to the discussion when the grammar
was being solidified.  I am certain that all of us would have preferred that
the grammar used RANGE-d0,d6 rather than the difficult-to-parse d0:d6.
Prefix languages are fun.  I suppose you are a real lisp fan.  D'ja ever
try writing an APL parser?  That's pretty interesting.

I'm a little worried that we might have pushed back a little on getting
rid of comments.  Text based protocols being human readable, one often does
like
comments from time to time.  Turns out many real applications use fixed
hunks
of message text to accomplish tasks. Messages that humans write, and others
read.  'Course writing a parser for a text based grammar that includes
comments
might be considered difficult if only we hadn't gotten so used to them with
compilers and interpreters and just about everything else that uses a
parser,
right?

I like the suggestion I heard that you should have a runtime -verbose switch

which when on uses long tokens and leaves comments, when off uses short
tokens
and suppresses comments.

I actually would have tried to fix the shift-reduce issue.  That is
unnecessary,
but it's too late now.  We did fix several of these kinds of problems as we
developed the grammar.  There were 2-3 groups who were writing and modifying
parsers as the grammar evolved.  We made many edits as these brave souls
tried
to keep up with us and discovered ambiguities.  I believe the grammar can be

pretty easily fit into an LL(1) parser, and we have reports of several
others.
Lots of folks used yacc/lex which is LALR(1).

There were 12 or so DIFFERENT parsers at the first interop event.  No one
seemed
to have great difficulty with the grammar.  It's not a simple grammar, so
the
parsers aren't simple, but quite a few people have dealt with it.

Brian


> -----Original Message-----
> From: Tulpule, Naren [mailto:naren@TRILLIUM.COM]
> Sent: Thursday, December 07, 2000 4:29 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: clarification in SDP parsing (octet string ) in Local
> descrip tor
>
>
> Hi Troy, Govinda and list,
>   First, Govinda - IN IP4 $ is not in RFC2327 (SDP) as it is
> now, but very
> likely will be added. You can take a look at the MMUSIC
> drafts - they're
> recirculating the SDP RFC, plus adding ability to describe
> ATM parameters
> (http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-atm
> -02.txt) among
> others. I don't know which RFC or draft the a=fmtp line came
> from though -
> it doesn't comply with RFCs 2733, 2833 or 2848. Good thing
> the Megaco spec
> says it's only an example :-)
>   Troy - I agree with you, they had absolutely no need to
> bend the SDP RFC.
> They could have chosen to terminate SDP announcements with an
> invalid line
> (e.g. "==" EOL). There are other improvements possible in the
> grammar of
> course but perhaps it's too late now. Examples -
> 1. To know if a parmValue is a list-of-ANDed-values ("[
> VALUE, VALUE, ...]")
> or a range of values ("[ VALUE : VALUE]") you need to go past
> the first
> VALUE when a prefix ("AND-" and "RANGE-") could have solved
> the problem
> easily.
> 2. Ability to have comments embedded in the message seems really
> superfluous. Is the MGC going to tell the MG "Keep up the
> good work" or
> something :-) ? No Occam's razor was applied at any point in
> writing the
> grammar.
> 3. There is a shift-reduce conflict when an MID is an MTP address, and
> supposed to be followed by a SEP, because MTP address ends
> with a RBRKT
> which ends with an LWSP. All parser builders would resolve it
> in favor of
> shift but the grammar needs a reduce at this point.
>     These are not unsurmountable difficulties of course, just
> unnecessary,
> and contribute to complicate the pasring code in logic, code size and
> runtime efficiency.
>
> -- Naren.
> These views and opinions are mine alone, not those of Intel
>  (yet ;-)
> Narendra C. Tulpule SMTS, Trillium (an Intel company)
> Ph: +1-310-442-9222              Fax: +1-310-442-1162
> 12100 Wilshire Bl #1800         Los Angeles, CA 90025
>
>
> -----Original Message-----
> From: Troy Cauble [mailto:troy@LUCENT.COM]
> Sent: Thursday, December 07, 2000 1:07 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: clarification in SDP parsing (octet string ) in Local
> descriptor
>
>
> Seems to me that the octetString can have a $.
> As for the SDP RFC, I guess they're bending the RFC.
>
>    octetString          = *(nonEscapeChar)
>    nonEscapeChar        = ( "\}" / %x01-7C / %x7E-FF )
>
> -troy
>
> Panditha Govindaraj wrote:
> >
> > Hi
> >
> >         In the Example call flow of MEGACO RFC 2885
> >
> > The local descriptor :
> >
> > The local token follows by an octet string
> >
> > This Octet string is the part of SDP grammar, In the SDP grammar
> >
> > it is no where shown that the octet string can have a $
> (does this mean
> > choose wild card) if yes how is this to be handled, as RFC
> 2327 for SDP
> >
> > does not support the ($) & ( VAD=X-NNVAD ) operation , How
> is this suppose
> > to be handles in the SDP Parser of Megaco
> >
> > Can somebody suggest me
> >
> > Here is a copy of the Example
> >
> > Local {
> >    v=0
> >    c=IN IP4 $
> >    m=audio $ RTP/AVP 4
> >    a=ptime:30
> >    v=0
> >    c=IN IP4 $
> >    m=audio $ RTP/AVP 0
> > a=fmtp:PCMU VAD=X-NNVAD
> >                      }
> >
> > Thanks
> >
> > Govindaraj.P
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec  8 15:13:34 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07342
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Dec 2000 15:13:34 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0F4D@standards.nortelnetworks.com>; Fri, 8 Dec 2000 14:54:11 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3054 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 14:54:11 -0500
Received: from tnint06.telogy.com (mail.telogy.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC0F40@standards.nortelnetworks.com>; Fri, 8 Dec 2000
          14:44:11 -0500
Received: by argentina.telogy.com with Internet Mail Service (5.5.2448.0) id
          <YHM5T23F>; Fri, 8 Dec 2000 15:01:46 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <61891BA043DED21180920090273F173801C7B0D9@argentina.telogy.com>
Date:         Fri, 8 Dec 2000 15:01:46 -0500
Reply-To: Panditha Govindaraj <pgovindaraj@TELOGY.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Panditha Govindaraj <pgovindaraj@TELOGY.COM>
Subject:      Re: clarification in SDP parsing (octet string ) in Local descrip
              tor
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi Lsit

Sorry for Resending this once again,

iam resending this message as i have not got any solution to my previous
question ,

And i am in the process of implementing this.

So I would like some one in the List to answer my question, As I can keep my
SDP

Parser implementation work movinf.

Govind




Hi Naren,Troy and list



Does this mean that i need to parse the Grammar in the
draft-ietf-mmusic-sdp-atm-02.txt
and not RFC 2327
and one more thing , How do I parse VAD=X-NNVAD and when does this occur,
Where is this defined in the grammar,

This indicates Voice activity Detection though it is in Example of MEgaco
Specs but
this is still valid. Can you help me to find a clarification on this.

As of now i have written a parser for the grammar in RFC 2327 which is SDP
,to parse the octet string in Local & Remote
Descriptors.
Do I need to parse the Remote descriptor using RFC 2327
and write a different parser for Local descriptor which parses the grammar
in
draft-ietf-mmusic-sdp-atm-02.txt
but still the VAD=X-NNVAD is not clarified

We have written our own parser , Where we parse each token

This was not mentioned the RFC 2885 right

Please clarify me , Expecting a reply soon.

Govind


-----Original Message-----
From: Tulpule, Naren [mailto:naren@TRILLIUM.COM]
Sent: Thursday, December 07, 2000 4:29 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: clarification in SDP parsing (octet string ) in Local
descrip tor


Hi Troy, Govinda and list,
  First, Govinda - IN IP4 $ is not in RFC2327 (SDP) as it is now, but very
likely will be added. You can take a look at the MMUSIC drafts - they're
recirculating the SDP RFC, plus adding ability to describe ATM parameters
(http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-atm-02.txt) among
others. I don't know which RFC or draft the a=fmtp line came from though -
it doesn't comply with RFCs 2733, 2833 or 2848. Good thing the Megaco spec
says it's only an example :-)
  Troy - I agree with you, they had absolutely no need to bend the SDP RFC.
They could have chosen to terminate SDP announcements with an invalid line
(e.g. "==" EOL). There are other improvements possible in the grammar of
course but perhaps it's too late now. Examples -
1. To know if a parmValue is a list-of-ANDed-values ("[ VALUE, VALUE, ...]")
or a range of values ("[ VALUE : VALUE]") you need to go past the first
VALUE when a prefix ("AND-" and "RANGE-") could have solved the problem
easily.
2. Ability to have comments embedded in the message seems really
superfluous. Is the MGC going to tell the MG "Keep up the good work" or
something :-) ? No Occam's razor was applied at any point in writing the
grammar.
3. There is a shift-reduce conflict when an MID is an MTP address, and
supposed to be followed by a SEP, because MTP address ends with a RBRKT
which ends with an LWSP. All parser builders would resolve it in favor of
shift but the grammar needs a reduce at this point.
    These are not unsurmountable difficulties of course, just unnecessary,
and contribute to complicate the pasring code in logic, code size and
runtime efficiency.

-- Naren.
These views and opinions are mine alone, not those of Intel    (yet ;-)
Narendra C. Tulpule SMTS, Trillium (an Intel company)
Ph: +1-310-442-9222              Fax: +1-310-442-1162
12100 Wilshire Bl #1800         Los Angeles, CA 90025


-----Original Message-----
From: Troy Cauble [mailto:troy@LUCENT.COM]
Sent: Thursday, December 07, 2000 1:07 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: clarification in SDP parsing (octet string ) in Local
descriptor


Seems to me that the octetString can have a $.
As for the SDP RFC, I guess they're bending the RFC.

   octetString          = *(nonEscapeChar)
   nonEscapeChar        = ( "\}" / %x01-7C / %x7E-FF )

-troy

Panditha Govindaraj wrote:
>
> Hi
>
>         In the Example call flow of MEGACO RFC 2885
>
> The local descriptor :
>
> The local token follows by an octet string
>
> This Octet string is the part of SDP grammar, In the SDP grammar
>
> it is no where shown that the octet string can have a $ (does this mean
> choose wild card) if yes how is this to be handled, as RFC 2327 for SDP
>
> does not support the ($) & ( VAD=X-NNVAD ) operation , How is this suppose
> to be handles in the SDP Parser of Megaco
>
> Can somebody suggest me
>
> Here is a copy of the Example
>
> Local {
>    v=0
>    c=IN IP4 $
>    m=audio $ RTP/AVP 4
>    a=ptime:30
>    v=0
>    c=IN IP4 $
>    m=audio $ RTP/AVP 0
> a=fmtp:PCMU VAD=X-NNVAD
>                      }
>
> Thanks
>
> Govindaraj.P


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec  8 15:26:59 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11980
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Dec 2000 15:26:57 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0F6C@standards.nortelnetworks.com>; Fri, 8 Dec 2000 15:07:28 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3101 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 15:07:28 -0500
Received: from zmers013 (47.124.1.40:34461) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC0F65@standards.nortelnetworks.com>; Fri, 8 Dec 2000 14:57:28
          -0500
Received: from smtprch1.nortel.com (actually erchg0j) by zmers013; Fri, 8 Dec
          2000 15:10:42 -0500
Received: from ztcfd004.ca.nortel.com by smtprch1.nortel.com; Fri, 8 Dec 2000
          14:10:33 -0600
Received: from americasm10.nt.com (michael-brown.us.nortel.com [47.142.213.27])
          by ztcfd004.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2652.39) id XNYRVSLX; Fri, 8 Dec 2000 15:10:25
          -0500
X-Sybari-Space: 00000000 00000000 00000000
X-Sender: "Michael Brown" <mahubard@ztcfd004>
X-Mailer: Mozilla 4.7 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
References: <28560036253BD41191A10000F8BCBD110312A3BA@zcard00g.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3A314230.EB7062E0@americasm10.nt.com>
Date:         Fri, 8 Dec 2000 15:18:56 -0500
Reply-To: "Brown, Michael [NC1:3T65:EXCH]"              <C.Michael.Brown@AMERICASM10.NT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Brown, Michael [NC1:3T65:EXCH]"              <C.Michael.Brown@AMERICASM10.NT.COM>
Organization: Nortel Networks
Subject:      Re: DEVELOPMENT OF CALL BEARER CONTROL PROTOCOL Q.CBC,
              B ASED ON H.248
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

I was at the SG11 meeting this last week and feel that this should definitely be
on the agenda for discussion. I would strongly encourage people to obtain a copy
of the referenced TD.

Michael Brown

"Taylor, Tom-PT [NORSE:B901:EXCH]" wrote:

> Thanks for letting us know.  Would you like this added to the Megaco meeting
> agenda for discussion?  I can present if you're not available (Christian
> won't be there, he told me).
>
> -----Original Message-----
> From: Greg Ratta [mailto:gratta@LUCENT.COM]
> Sent: Wednesday, December 06, 2000 12:50 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: [MEGACO] DEVELOPMENT OF CALL BEARER CONTROL PROTOCOL Q.CBC, BASED
> ON H.248
>
> This message represents a communication to the IETF MEGACO WG that was
> approved by ITU-T SG 11 at its December 6, 2000 meeting.
>
> With this communication statement, we would like to inform you on the
> development by Study Group 11 of the Call Bearer Control protocol, Q.1950.
> Should you like to review the current draft, please send an email request
> for the Acrobat PDF version of 'TD PL/11-90' to Christian Groves { HYPERLINK
> mailto:Christian.Groves@ericsson.com) }(Christian.Groves@ericsson.com), who
> is active in your IETF WG. This activity is now approaching its completion.
>
> The Call Bearer Control protocol specifies a 'vertical' interface between a
> Call Control entity and a Bearer Control entity. This enables the offering
> of a full set of telephony (BICC) services, independent of the underlying
> transport network.
>
> The Call Bearer Control protocol has been based on the SG16 protocol H.248.
> It uses the H.248 format, H.248 descriptors, H.248 encoding, H.248 defined
> packages, etcetera. Seven new H.248 packages have been defined.
>
> Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and
> protocols
>
> Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196,
> gratta@lucent.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec  8 15:40:48 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17571
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Dec 2000 15:40:48 -0500 (EST)
Received: from standards (47.234.32.16:1286) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC0F99@standards.nortelnetworks.com>; Fri, 8 Dec 2000 15:21:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3143 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 15:21:23 -0500
Received: from netmail2.alcatel.com (mail2.alcatel.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC0F85@standards.nortelnetworks.com>; Fri, 8 Dec 2000
          15:11:22 -0500
Received: from relay2.usa.alcatel.com (relay2.usa.alcatel.com [143.209.238.7])
          by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id OAA03107 for
          <megaco@standards.nortelnetworks.com>; Fri, 8 Dec 2000 14:29:06 -0600
          (CST)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by
          relay2.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id OAA07217 for
          <megaco@standards.nortelnetworks.com>; Fri, 8 Dec 2000 14:29:08 -0600
          (CST)
Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com
          [143.209.151.53]) by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP
          id eB8KSld27831 for <megaco@standards.nortelnetworks.com>; Fri, 8 Dec
          2000 14:28:47 -0600 (CST)
Received: from usa.alcatel.com (localhost [127.0.0.1]) by
          sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id
          eB8KSk024868 for <megaco@standards.nortelnetworks.com>; Fri, 8 Dec
          2000 14:28:46 -0600 (CST)
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <3A2D2732.894B17D3@usa.alcatel.com>
            <3A301413.B386DBB4@americasm01.nt.com>
            <3A30EBA9.A3DCDB98@usa.alcatel.com>
            <3A312D56.E2954351@americasm01.nt.com>
Content-Type: multipart/alternative;
              boundary="------------44B193B0BC9BF72FA59B7E12"
Message-ID:  <3A31447E.F6AC0947@usa.alcatel.com>
Date:         Fri, 8 Dec 2000 14:28:46 -0600
Reply-To: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Subject:      Re: [Fwd: ServiceChange corrections in Implementers Guide]
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

You are missing the point.
ServiceChange w/Forced or Graceful comes before ServiceChange w/Restart
in different
messages.

I am looking at error handling.
MG did not send ServiceChange w/Restart but started sending
ServiceChange w/Forced/Graceful.



Kevin Boyle wrote:

> I would say that the MGC will process them like any other
> communication from the MG: in the order of receipt.  That is, the MGC
> will finish processing the Restart, and then process the
> Forced/Graceful appropriately.
>
> Kevin
>
> Chuong Nguyen wrote:
>
>> Ok I miss read the thing.
>>
>> I wanted to ask about Error code for MGC to send to MG if MG sends
>> up any command
>> before MG does a ServiceChange with Restart.
>>
>> Said if MGC receives ServiceChange w/Forced/Graceful before
>> receiving ServiceChange
>> w/Restart from MG, what should the MGC do:
>>
>> 1) ignore the ServiceChange w/Forced/Graceful?
>> 2) send a ServiceChange reply w/an Error code of ????
>>
>> Thanks
>> Chuong
>>
>> "Boyle, Kevin [NCRTP:3Z70:EXCH]" wrote:
>>
>> > Comments inline below [KJBII]
>> >
>> > Kevin
>> >
>> > Chuong Nguyen wrote:
>> >
>> >>  Ops.  One more point in Section 11. last paragraph
>> >>
>> >>  "The MG shall issue error 505 - Command Received before Restart
>> >>  Response."
>> >>  The "MG" should be "MGC".
>> >>
>> >
>> > [KJBII] Actually, the text is correct.  This error indicates that
>> > the MG received a command from the MGC before it received the MGC's
>> > response to the ServiceChange Restart.
>>
>> >
>> >
>> >>
>> >>  This also brings up an interesting point.
>> >>
>> >>  For sure error 505 applies to all commands before Restart but
>> >>  there are exception for ServiceChange.
>> >>
>> >>  For ServiceChange w/method Forced/Graceful, MGC should response
>> >>  w/error 505.
>> >>  For ServiceChange w/method HandOff or Failover, MGC should either
>> >>  accept the
>> >>  registration or provide alternative MGC to try.
>> >>
>> >>  Are the above assumption correct?
>> >>
>> >
>> > [KJBII] In these cases, the MG is in an active communication state
>> > with the MGC, and then decides that it needs to go out of service.
>> > The MGC may be in the process of sending a command while the MG is
>> > sending the ServiceChange, and the commands "cross in the mail", so
>> > to speak.  In this case, the MG shouldn't reject the commands -- in
>> > fact, it should continue to execute the commands if it can, until
>> > it recieves the MGC's response to the Service Change, effectively
>> > taking the MG out of service.
>> >
>> >>
>> >>  Thanks
>> >>  Chuong
>> >>
>> >>  Chuong Nguyen wrote:
>> >>
>> >> > Hi Christian
>> >> >
>> >> > I don't know if this was pointed out already.
>> >> > I am looking at H248_Implementors_guide_approved.zip.
>> >> >
>> >> > The change for Section 6.3  Cold Start has the following:
>> >> > "If the MGC accepts the MG, it will send a Transaction Reply,
>> >> > with the ServiceChangeMgcId
>> >> > set to itself."
>> >> >
>> >> > The change for Section 11.2 Cold Start has the following:
>> >> > "If the MGC accepts the MG's resignation, it sends a
>> >> > Transaction Reply not including a
>> >> > ServiceChangeMgcId parameter."
>> >> >
>> >> > This 2 statements contradict each other.
>> >> > I think originally it was always "not" including a
>> >> > ServiceChangeMgcId parameter.
>> >> >
>> >> > Also additional words might be added to clearly stated that
>> >> > "If the MG receives a Transaction Reply that includes a
>> >> > ServiceChangeMgcId parameter, it sends
>> >> > a ServiceChange w/a method of Restart to the MGC specified in
>> >> > the ServiceChangeMgcId."
>> >> >
>> >> > Otherwise someone might get confused and use ServiceChange w/a
>> >> > method of handoff.
>> >> >
>> >> > Chuong
>> >>
>> --
>>   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>>   **** The opinions expressed are not those of Alcatel USA, Inc ****
>>
>>
>
--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body text="#000000" bgcolor="#FFFFFF" link="#0000FF" vlink="#FF0000" alink="#000088">
You are missing the point.
<br>ServiceChange w/Forced or Graceful comes before ServiceChange w/Restart
in different
<br>messages.
<p>I am looking at error handling.
<br>MG did not send ServiceChange w/Restart but started sending ServiceChange
w/Forced/Graceful.
<br>&nbsp;
<br>&nbsp;
<p>Kevin Boyle wrote:
<blockquote TYPE=CITE>I would say that the MGC will process them like any
other communication from the MG: in the order of receipt.&nbsp; That is,
the MGC will finish processing the Restart, and then process the Forced/Graceful
appropriately.
<p>Kevin
<p>Chuong Nguyen wrote:
<blockquote TYPE=CITE>Ok I miss read the thing.
<p>I wanted to ask about Error code for MGC to send to MG if MG sends up
any command
<br>before MG does a ServiceChange with Restart.
<p>Said if MGC receives ServiceChange w/Forced/Graceful before receiving
ServiceChange
<br>w/Restart from MG, what should the MGC do:
<p>1) ignore the ServiceChange w/Forced/Graceful?
<br>2) send a ServiceChange reply w/an Error code of ????
<p>Thanks
<br>Chuong
<p>"Boyle, Kevin [NCRTP:3Z70:EXCH]" wrote:
<blockquote TYPE=CITE>Comments inline below [KJBII]
<p>Kevin
<p>Chuong Nguyen wrote:
<blockquote TYPE=CITE>Ops.&nbsp; One more point in Section 11. last paragraph
<p>"The <b>MG</b> shall issue error 505 - Command Received before Restart
Response."
<br>The "MG" should be "MGC".
<br>&nbsp;</blockquote>
[KJBII] Actually, the text is correct.&nbsp; This error indicates that
the MG received a command from the MGC before it received the MGC's response
to the ServiceChange Restart.</blockquote>

<blockquote TYPE=CITE>&nbsp;
<blockquote TYPE=CITE>&nbsp;
<br>This also brings up an interesting point.
<p>For sure error 505 applies to all commands before Restart but there
are exception for ServiceChange.
<p>For ServiceChange w/method Forced/Graceful, MGC should response w/error
505.
<br>For ServiceChange w/method HandOff or Failover, MGC should either accept
the
<br>registration or provide alternative MGC to try.
<p>Are the above assumption correct?
<br>&nbsp;</blockquote>
[KJBII] In these cases, the MG is in an active communication state with
the MGC, and then decides that it needs to go out of service.&nbsp; The
MGC may be in the process of sending a command while the MG is sending
the ServiceChange, and the commands "cross in the mail", so to speak.&nbsp;
In this case, the MG shouldn't reject the commands -- in fact, it should
continue to execute the commands if it can, until it recieves the MGC's
response to the Service Change, effectively taking the MG out of service.
<blockquote TYPE=CITE>&nbsp;
<br>Thanks
<br>Chuong
<p>Chuong Nguyen wrote:
<blockquote TYPE=CITE>Hi Christian
<p>I don't know if this was pointed out already.
<br>I am looking at H248_Implementors_guide_approved.zip.
<p>The change for Section 6.3&nbsp; Cold Start has the following:
<br>"If the MGC accepts the MG, it will send a Transaction Reply, with
the ServiceChangeMgcId
<br>set to itself."
<p>The change for Section 11.2 Cold Start has the following:
<br>"If the MGC accepts the MG's resignation, it sends a Transaction Reply
<b>not
</b>including
a
<br>ServiceChangeMgcId parameter."
<p>This 2 statements contradict each other.
<br>I think originally it was always "not" including a ServiceChangeMgcId
parameter.
<p>Also additional words might be added to clearly stated that
<br>"If the MG receives a Transaction Reply that includes a ServiceChangeMgcId
parameter, it sends
<br>a ServiceChange <b>w/a method of Restart </b>to the MGC specified in
the ServiceChangeMgcId."
<p>Otherwise someone might get confused and use ServiceChange w/a method
of handoff.
<p>Chuong</blockquote>
</blockquote>
</blockquote>

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

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

--------------44B193B0BC9BF72FA59B7E12--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec  8 17:05:26 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA09411
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Dec 2000 17:05:25 -0500 (EST)
Received: from standards (47.234.32.16:2324) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC1056@standards.nortelnetworks.com>; Fri, 8 Dec 2000 16:46:10 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3432 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 16:46:10 -0500
Received: from auemail2.firewall.lucent.com (auemail2.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC1055@standards.nortelnetworks.com>; Fri, 8 Dec 2000
          16:46:10 -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 RAA29570
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 8 Dec 2000 17:03:55
          -0500 (EST)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by
          auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id RAA29566
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 8 Dec 2000 17:03:55
          -0500 (EST)
Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id RAA08660; Fri, 8 Dec
          2000 17:03:53 -0500
Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id
          RAA08657; Fri, 8 Dec 2000 17:03:52 -0500
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3A315A7A.3DD7117C@lucent.com>
Date:         Fri, 8 Dec 2000 17:02:34 -0500
Reply-To: Troy Cauble <troy@bell-labs.com>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Troy Cauble <troy@LUCENT.COM>
Subject:      MEGACO: DigitMapName question
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

In the ASN.1 encoding a DigitMapName is two octets.

In the ABNF encoding a digitMapName is up to 64
alphanumerics and underbars.


Are these arbitrary schema like the TerminationID?
So any mapping between ASN.1 and text are application
specific?

I don't suppose anyone wants to limit the ABNF
to match the ASN.1...

-troy


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec  8 17:20:41 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13414
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Dec 2000 17:20:40 -0500 (EST)
Received: from standards (47.234.32.16:2324) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC107B@standards.nortelnetworks.com>; Fri, 8 Dec 2000 17:01:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3483 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 17:01:23 -0500
Received: from auemail2.firewall.lucent.com (auemail2.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC107A@standards.nortelnetworks.com>; Fri, 8 Dec 2000
          17:01: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 RAA08002
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 8 Dec 2000 17:19:08
          -0500 (EST)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by
          auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id RAA07996
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 8 Dec 2000 17:19:08
          -0500 (EST)
Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id RAA08844; Fri, 8 Dec
          2000 17:19:06 -0500
Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id
          RAA08841; Fri, 8 Dec 2000 17:19:05 -0500
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3A315E0A.F6AD3957@lucent.com>
Date:         Fri, 8 Dec 2000 17:17:46 -0500
Reply-To: Troy Cauble <troy@bell-labs.com>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Troy Cauble <troy@LUCENT.COM>
Subject:      MEGACO: ServiceChangeProfile/Name question
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

In the ASN.1 encoding, a ServiceChangeProfile/Name is two octets.

In the ABNF encoding, a serviceChangeProfile/NAME is up to 64
alphanumerics and underbars.


Are these arbitrary schema like the TerminationID?
So any mapping between ASN.1 and text are application
specific?

-troy


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec  8 17:30:24 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16132
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 8 Dec 2000 17:30:23 -0500 (EST)
Received: from standards (47.234.32.16:2324) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC109A@standards.nortelnetworks.com>; Fri, 8 Dec 2000 17:10:58 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 3525 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 8 Dec 2000 17:10:57 -0500
Received: from auemail2.firewall.lucent.com (auemail2.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC1099@standards.nortelnetworks.com>; Fri, 8 Dec 2000
          17:10: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 RAA12455
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 8 Dec 2000 17:28:43
          -0500 (EST)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by
          auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id RAA12451
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 8 Dec 2000 17:28:42
          -0500 (EST)
Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id RAA08974; Fri, 8 Dec
          2000 17:28:40 -0500
Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id
          RAA08971; Fri, 8 Dec 2000 17:28:39 -0500
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <3A315E0A.F6AD3957@lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3A316049.D30F85F@lucent.com>
Date:         Fri, 8 Dec 2000 17:27:21 -0500
Reply-To: Troy Cauble <troy@bell-labs.com>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Troy Cauble <troy@LUCENT.COM>
Subject:      Re: MEGACO: ServiceChangeProfile/Name question
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Troy Cauble wrote:
>
> In the ASN.1 encoding, a ServiceChangeProfile/Name is two octets.
>
> In the ABNF encoding, a serviceChangeProfile/NAME is up to 64
> alphanumerics and underbars.
>
> Are these arbitrary schema like the TerminationID?
> So any mapping between ASN.1 and text are application
> specific?
>
> -troy

And are Profile numbers another thing to be run
through IANA?

-troy


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sat Dec  9 02:28:21 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA19449
	for <megaco-archive@LISTS.IETF.ORG>; Sat, 9 Dec 2000 02:28:20 -0500 (EST)
Received: from standards (47.234.32.16:3513) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC1209@standards.nortelnetworks.com>; Sat, 9 Dec 2000 2:09:04 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4005 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 9 Dec 2000 02:09:04 -0500
Received: from mail.pi.se by standards.nortelnetworks.com (LSMTP for Windows NT
          v1.1b) with SMTP id <0.FFBC1207@standards.nortelnetworks.com>; Sat, 9
          Dec 2000 2:09:01 -0500
Received: from ru (ap03-036.mp.pi.se [195.7.87.36]) by mail.pi.se (8.8.8/8.8.8)
          with SMTP id IAA28146; Sat, 9 Dec 2000 08:23:21 +0100 (MET)
MIME-Version: 1.0
Content-Type: multipart/mixed;
              boundary="----=_NextPart_000_0000_01C061B9.76580D60"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Importance: Normal
Message-ID:  <NEBBJHOEEMOJCNLMMHGEAEJICMAA.gunnar.hellstrom@omnitor.se>
Date:         Sat, 9 Dec 2000 08:24:34 +0100
Reply-To: Gunnar Hellstrom <gunnar.hellstrom@OMNITOR.SE>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Gunnar Hellstrom <gunnar.hellstrom@OMNITOR.SE>
Subject:      SV: Conflicting packageIDs
X-To:         "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <28560036253BD41191A10000F8BCBD110312A2FC@zcard00g.ca.nortel.com>

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01C061B9.76580D60
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Sachin and all,

The observation that package txp has a wrong number in H.248 Annex F is
definitely right.
The number for txp should be 0x0010

The numbers were aligned last spring according to the attached TD, but for
txp I apparently missed to hex convert the number. I will initiate
corrections.

Regards
Gunnar Hellström


> -----Ursprungligt meddelande-----
> Frĺn: Media Gateway Control (megaco)
> [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]För Taylor, Tom-PT
> [NORSE:B901:EXCH]
> Skickat: den 8 december 2000 17:39
> Till: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Ämne: Re: Conflicting packageIDs
>
>
> The packages have different numbers in the IANA registration page at
> http://www.isi.edu/in-notes/iana/assignments/megaco-h248
> Where did you get your numbers?
>
> The R2 package got caught up in the general discussion on CAS, so there is
> no package number yet.  I assume one of your Hughes colleagues is a member
> of the CAS design team.
>
> > -----Original Message-----
> > From: Sachin Sikri [mailto:ssikri@HSS.HNS.COM]
> > Sent: Wednesday, December 06, 2000 1:45 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: [MEGACO] Conflicting packageIDs
> >
> >
> > Hi
> >
> >  Text Telephone package defined in Annex F and Keypad Package
> > defined in Annnex
> > G have conflicting package IDs as 0x0016.
> > As per my thinking package ID for Text Telephone package
> > should be 0x0010
> > (Correct me if i am wrong).
> > Also if anybody can tell me the package ID for R2 package.
> >
> > Regards
> > Sachin Sikri
> > Hughes Software System
> >
>

------=_NextPart_000_0000_01C061B9.76580D60
Content-Type: application/x-zip-compressed;
        name="Td-14.zip"
Content-Disposition: attachment;
        filename="Td-14.zip"
Content-Transfer-Encoding: base64

UEsDBBQAAAAIAA0Zryiq3Gp7WRcAAACUAAAJAAAAVEQtMTQuZG9j7J0LfFTVncfPnUxyJ0DIg1cQ
1CtQRR5DZvKOggl5ER4JkAA+eN3M3CQDk5lxZhIS2Fapsdrdbj+4bn0/sG63rFqLj1bXtUhbP/VR
XW1XbV3FUj/62W1XdxH4KKAk+/vfOxPOPE4yJCGCzj98587/nvM/59zzuvfM/d/L669lH3zgsfP+
zKJkEUthvX3pLI3bJ4HqsJLFWG1oX29fXx/tqgJ9STmn5KMf/ZJdxdLNaLqc5/pbFoI9741jbDxr
3tK85ci6I+tYjKSbJ7ML5jF2y0JJ5wYLY1fHRuuXvr7MQb+HZYP+6ZdY/5YYg+9/gy0Kxm4OhfHb
iVwK90iDbymdPdiu5/Z/q4CxefiumAx9qNtKpENfqwsMPZHtLGwfKmTsKPK/r5ixu6C7sH8Si5Xw
cYfzi5bByucqiNSj6zM63dM9/uh0ovXKUP7REt1O8dqZ30anR/pfTaf2j0ll7Bl0nFfnMvaIHGs/
VKmMqj8zttOx3d3cK9Xse06KPo5wvO58xl5mZ4vUNa1RmjS35vC2t3d4XA416PJ6lMag6nGqfqdr
e0jXHEGvP52kqUqZr9gKMhqDHc5updbv7fAptqKMVVabfb6tYIGtSFmt+nxef1Dr8CsrNC3o8rRm
NATUreo8xVao3KbYSpUVardiz8vLy8jIaGxYs7qyenaZUtmmuvztqkfxtih11U01sG1VHV5lnde/
FUmEcprd5G1XmtRut9d/aUZGU13T8uqy9JV+r88b0JyUhqdVCyhNXmWJ1V5QoqxUHVvVVk2p72hv
1vxUkk2nKxkZ69pcbk3x+TWfSkkowTZNCarN2Ieiqm63F5WGzI0cfaEcXU7NE3S1uDR/QGnx+pW6
ivqKebqp2hFsww6Pl4xohy+gdTi98/2ochxcsxpwBRTU+bY2l6ONInQrbWqnpjRrmofLzuVRtC5X
gKpXcWpBzd/u8lCCWlfQqihNpzJCCn4NRaBD0OspgF1q0Ei5WVMceqXpCaoOh9fvVD0OTdnmCuqZ
o/DIcpt+3HTM1oyMBrcTHcLvUt1Kvdcq12vbeDVU5XJjUK+serVdk9dqfqtc3RXUPM6AEtDjLuhE
zaBr6amRIBm5yuvoaEe96Z1OlvPwV4/vnVTfrQG53htUOtDOsk2eL+vV3WlTKjwerUuplGVbAfbX
ah4k75Bbo+Mo1VYb4hTKdnmxGtAUv9cblPWP2Ih2RJTz5SavR1NaKUEVnV8OQoUWJ36+jFQLjPjU
FA69+BQfWpz4BTJSL6RyuBxKVdOKGi4XJ5XctsCmGJK/wBZlXCgjqyJZNzuVmZMqxd5vVhBjViQj
x2K5Eh2I+kGrXwugH6CIAS5zx2CZF8vIuiRuKqfK4hisLCWyXIq/Co/q9rZ2aIobPVcJdPg0f6eL
+oSsuuPUWilaJY/+GfXm8GJ8eTpcwW7ZEVPJ6BFo7zxY2OhfvRbchmlE9ggiUs+w07/VTStlf9BH
tRCuBvoSa0FdJJ/+NVWtUBwuvwMFkYPOdsfgpugt+XbqrTUVVyoLMPl2BX1t1HUWKCu8Tg3Tm16f
Vf312RJsH7hGa6hHFRZS76bUqGpodBmjKNjliKnMGupFhUWyrcgwCOIEoJcBsX1xYlPnKZZtoe4T
7Pahn7sCDr8Lc46RiwM74xhSf8GwLKFjlVvUrjhR0BmKUPRSuW6lQrFcvvjx0Pz5xbI9T65yBXxu
tVtGCWKi1VoRq0S22+RlWre8FcSNUSrb7RTDpzrlrVTu/JJQ5dqjmkyPX5An2/Pl5Wqz5lYoTTd9
MxIfxBCthnbu8OgNqdtubYFVQV7YKnqI6VZ22V4o13mcdDbGqHR5YmY8I16+bC+SG70tQSPlwOAp
F8j2Yow7h8vtVv3dmPJ9HUEZ870rfj0hgxK5qtujtmPABY3prcXlcRlTTjC2WEthhCm2NDwPK6rH
48XhazSrI6MYg2WynDFbqcRYVh3BMiX91Ok9Iz29ul11ucsw95Ne7qFrCrfHGMoBKy5YEAWXLsjD
ST2nTJlrU4ps+UpxfpGSV1pkw9XF4Nc/X3vBOq8IlIDvgJvA3Vj03wNuwPKoZ5yxDmQn2WfsEEjK
OSXjKpfmsoalKWwVYGPSt0hszqG8pVjjpxRadrJ0av9SsAS0gG+B68D14FnwC3AIzMAqaiawo1/k
g8VgFbgKaGAL2An+Pu1U/7kP7AaPpFH34eQsUz7nlWOjpLz9dELRIhRDLmBs8ixpyizJdJubpb6V
a8YCMx6Wt3KY/I9976VMtqyd8GhuzrQrlYmzU3RjJuUYP91NHa32/xl4CvwreAm8DF4Fr4E/gLfB
O+AA+Bj8L/gEHKG+A0xYuZtBGpgMpoCpYBqYA+ygABSBGlAL6sAycDVoBk7QAjrBNtANdoBd4Fbw
A/AgeAI8CX4OngYvgJfBK+A/wV/B/4CPwf+BDAtjWSAHKCAP2EA+KASNYC24ErSATrANdIMd4AeW
yAY+eUKXYyc+Nb4kuD024BbpmlIkZpIkZk6RUsewFBP6gDpabfMFf4AJKgd2JRRt2MqBf0oo2vDz
2Z9QNLESKSMxD0wdrXEzWlWUaD5HE4o2/HzeTSjal9f+Z3JOuwPcBe6xDFhFudwPsWeyKUYrnz8m
FO0saf/odnoE/ATsBU+A58EL4CXwW/Ae+BN4H3wIPgaHwGFwFMjpyBCMBeNBDpgMcsHFoBSUgYWg
HCwHq0AjUEEQdIAusAM8CPaAh8DT4EXwEngFvAb+DD4E/wX+Ao6DE+AkoNtFmWACmASmgEvAbDAX
WEEtWA7qwUqwGajACVrBVuAF14IAuAH0gJvA34JbwO3gTnA3eBg8An4KHh9j3HnYB/aDX4Hfgd+D
N8EfwbvgIHgfnIR8ftKQyO1xwVYUX7SlbkNXAHQloF8FNI9Wm0cOkRc55UwOxdE6sY/S8UTKiIz/
0RqPBz/iSn6AP4yRVQ6u5Gb5M5nP85zCz/gjrBzkl4kkWIulzZLQdqEWHFYvYFNHa648k6Pvg4Si
DT+f7yUUbfj57BaFRMqIjP8zcR77ABwBR8Fn4MSIt/+BOxKKNvx8bk4o2vDz2Z9QtEgZkfYXtZc0
FsYgDUwEM8EscAmYAwrAQnAFWAHWgw1gM3AAHwiADnAD+AdwK7gN3AkeBD8G/wIeBs+AfwP7wC/B
y+BV8Bo4AD4CH4ND4AhIGYcDA2PAODANTAcXghmgDCwC5WAxWAlWgSawDriBF1wLAmAn+PY44zfv
u8AvwLvgQOj370SvxCL148c5nR3/9NPj4uY885JqymQZUsT1X91otfXwh8hozfJnbvkWmc/uhKKd
6fE/WuNwSFU0WsuEZxOKNvx83kgo2qi2/0jOkYlWA3/pfCarm1fe4ZW3E1MibCKUL1WkTOPezUi0
f850duHe1xcoew8uvGivRZ4BZu7anToLfGPvoCVJyjkvOWwCln4Su4ZlsrDD7yxMCZ/0mXRv5DRW
z7zMz9qZytzM8Gg2s/Ylusd4lFzOKsoP9z2ALToXq2Iaa4FVB+yCTGEr8d0PWvVPH2vDvhqk7UEo
L1Z2frnEDmPLWIYew4sYHv1Tg00TPrt0GxMjv/ESdnH5D5kklTA6mtj4q/VyaMhVw14HPnHWYkvm
SLC8Cjnl6JbjUF4vQjtwpJpeJoWt0MtJdZDN5lcpkoU1LDWzVaCM9TZIbIZUhlALcqhhlRElG4eS
ZPbslXKcWX2k8Tfhv8OMX9QMuYoZ3ucstBfT6DzGZP05irAPvkyBZuM+qj10P4V+tysN/bZyU+ia
nc7li0JzMWWAXWwsM7zcxwOqLXLuzwYTmOEtPymUNv0OTGsBsqWfA8h1JoeRbz5ZhnsB1agbBaxG
DaxHi3awZugu1Nt6VofjX8Pm41NhjawWnzZWhP2rsLVjv40VYF8DC6BWt4L1iFml7y9EWzv12o/M
x4pwymcF64ZldPsEEFIBPYj91MYObDv1dqbYlEun3v5etL4SkZeKUOeXmNdI11/BKNZfwZd8TGcu
n2ZmUcvMG3/4+N2xj6NIrMY0O1UU9oL5aGomSzfHC9t33XRZEoQ1K0/IojQfszwvtCubc8AiCvvD
dWVjdjlaGvoyo/8Yu3/RxrGicm6ceedYUZqTaqeMF4W9yjaNFx3Ds5nvjL8te/1P4pXl+9vTM0V2
R82Hsjo/mdUdL+zny0pzRGXJadyYI0pz2sLnJoiO/cebDk0Upfm+xztJFHb7NTMmi8KK03uEYXWr
758mKsukRV3ni+yW5bxyoSjsSMPViijsweU9M6YIwh6/5tffENm9Pblgrqicz9TdOFdU1/arZs4X
pZnruneBKOxP572ZJwr7j7wimyisfu5P7aIwx0Vz8kXH4Ki8N19kt+bqB4Rh8uLf5t/13B0V8fr1
2syTBaJ6eWPDt4tEYa61FSWisBmz1pWIynL5tGOlIrvfbHnqcpHd0c4DC0Vhj685uVCU5n1X+K8Q
2d3v2lgtCvuZy1Ujaod1rV1LRHYbXDuWiMqy4brvCsPaFi2uE4W5r/ndMuE4Gl+x/D7fW23xwh6b
lttweN7zl8ULu2NtY4Mov1/7pZWi/E7M/1AY1jXllkZRndVO//2aR3r39MYLe+eKv6wTpXl4e+/V
orAp5bUbRGE7gxM3Csd0hSIM29ni2yyql/MnW5qFc4G63ykK++dZzZoo7LP8HmHYk+cXtIjCbpqw
Rxj2YUdFqyhs3/KNwrA3Jpi2CMemvXeryG7v5Sc9wv7ZedgrSrN4Qaavaur3Lo4XVrb5Ip8ozZLz
/vtaUVjjppcDorCXZh4UhuWeVx8UhT16TXenKOzz1p3bRMfnKflkm8huns/cLbKbuiirW2TXu+3z
7l/t+Pe18cLeld/cLhp/R7u+EIYVr31+h6gs38z6WBj26ZovdojKeaPU8K1sQZgU2kZLChZ7mT2O
lOyeFb2TfpPKJEdKmne2voS3jqwR043apOyeOwyjNintlMWU2PhsbByLhqUSVsgSQ3YSe+rQkEs4
jPyGaJqqRxQV9XVTdk/eSd30dVOabhKOTHfxEzKheNZTbZ2SmphZasjMiurpN5XjmZaYs3te/Fw3
LTGTqcyZWpH/KfP0RMzTo8ytzMwnMTY2id2p2T2bT+hJ7E6lJMbGScKKQ+KT4R/xMZKxyNk9x47p
yVhkSiZDkIwVS8uIpLihJUgqc4CkrKixyOSyo5LzWbJ7dn2mJ+ezUHLZgyRnZZbRH3KjOVrNAxpF
5hc5CZkTHjlmFq7ksGGCYyeN8a3Tb5zY6LGw6KY9lUC88RPT+cfEJGCOTCSRETQubiKpUQklMIbG
CxNKi04sZhTFdPusAROTYxIcdBzlDJqgJZzo6fbQIRhdOtwRePafls85069B7ZjjHOIA8+iweqkx
9w5l3h5K1/46ddSveB8/zQvl5AmfSyR5wk89O0/4X87Udg5NpedIUYd8VjsbrvXOqv45cE1eiYl3
jzHxXhk9zQuNclP688uNutQ+x0fCwOdo8cFtxsGtNCw2j9zi4+t+xZS8Gk12hn75qpxP0wY0GmA+
Tvadr1q3G838xugRRfkNtNqLY3T6p8mhnljP8ot80WFdyprxSc4+fGRyMOB1cnDgdbppzOvk9MPr
5LjB6+T8wuvkcMbr5PTF63SDldfJcYHXyamC1+nGKq+TAw+v001ZXifHJ14n5wBeJ6cGXienA14n
5z1eJydAXidHJ14nhxteJ8c5XieHP16nm+u8To59vE7OUrxOTmW8To6HvE43unmdHLh4nRzWeJ0c
5nidnIJ4nW7i8zo5oPE6OQ7wOjkn8Do5JPA6OTXyOjnX8To5oPA6OZbwOjn88Do5UfA6OWrwOjln
8Do5g/E63VTndXJm5HVySON1chbgdXIq5HVyTuR1clThdXJ84HVymOJ1cs7hdXKG4HVyKOF1cgLi
dXKc5HVyKOB1ciTjdXLK4nVyUON1cuDkdXLA4HVysuJ1cqLhdXLe4nVyruJ1ctrgdXKM5HVytON1
cgLkdXJ65HVynOF1cobldXLq43VyTuJ1cs7gdXIU43Vy5OJ1cobjdXJo4nVy6uN1cqzjdXJc5HVy
5uN1crDhdXJg4nVyHuN1ch7ldXLq5XVydOV1chzh9cH+Q4CkjJZEnIbOYekrT7leYofwjXB+/0ZG
biqHQqHhrSk8a9JTLvvpAZVyprun1E7ehWsckyktJdWcakox32SKTP7+0LaJufRnFwJMYfXYbmP0
bI9XfzKJzkiFSMfEUlMlkySnmfp/tecn6+vpo5F1w6YZlvQ8U/7Feu5j08wmEmHuFcyP/I1noK4o
1G3klHSTKdVkFtpUIo8O3Y6eqgiXGiXtzxOHbEae2/WrvOvD81hf6KKvCfm1hY4QEwczM5vl5lzG
Xkd+bXoUubv64mxA3836HYTLsJ/exSfpHkNmXJzys7vhPxS+pNwZVe6knI78KG2//CR7Ep0qJ4+6
2VRG1wFTwb0RJ6ShidE0fX3ha495oWdcjKfM3KHnddrx14HeT0/BqCyILT1PR8/ABPVR4dSfuXNi
//aocLIP6s/VGBL5lE2klpSvrvT20SwROxHQHHHwxvsPH29oy3r4Fgube8kTb9N1GWZ6fUqlcHo5
ClnuAjTb0OP6tHaix9xpZqc3NtA0TKcAGhL0MDLdCp0oGc8WKpLxjOLlkvGM4hLJeO6wSTKeV9yM
LV3rtoXy9EnGc4tdkpHvB2b9IWhG66fT+X9MWIk174LQMTDYXRAqZ73+hnGm9YdBp+9jjbB21W11
eoOsPSq+k3QqTwEz4lMZV7gcfm+A3s2+zut3KsiRecspzWd3a5S2/v2hh/+uat9zkv69Zfkn1fie
EsqbtjSX67O4bGyTkpSkJCUpSUlKUpKSlKQkJSlJGaqI1v+0x/Tmq2/eY52WdevtWP/PO/5oFfal
Ru1bjzVqbmj9TuvWNmas2emeIf0GcD1juvcJ/VZAbr30WwHdD6cXuNK6ejcz1vZ7mLFu3svo3VGM
0WuP6beA/cxI+ziLXPPr6++G1U3Vy421Mf1ekMJBv8HRdkuWhYXvj4i2F2QZZT/t3xHGZRmFogLR
QTa5gm6NhZfw+jGG1+1KaCfdKyKTRSGdvtNvIJtW1lVtql1TV9V/lBXY1oMdLB9WJawaf8XYW4xy
2rENv9nGxqpYAb6VsEJsaV8e/opAKeKWIOZipJCPsG+ypCQlKUlJSlKSkpSkJCUpSUnK11XCa1DD
W8hYs9NSltbXdM8+9F8D9b9HmNbk0e8Spnv5/PuEaf3e29fXl8sMf5jzAPksTgfkW0zLZfLpVMBF
jDybGJvJ9PdOM/JlJnemS8BsRk7tjM0B5IM9jxlrdHozNPnskj8C+VaSv29+KM9CZqyxixm9GZox
8tWmtzRfFgon30xae5NPbjkzVtmLGflqGeEnQU3oe5ivspAHnVd/23W1/lZgevtvPPn/6ax0Z9jE
wPDhwFVmjwIg5gBikLgYAysjzCxQGmLjhIwlHYBoA28daDirUOSwbz/jgjNiTG5AGqSxAWquIXiV
WxJ4RRPolklQ+gKlyf//GRnQwX8gfrLanaHgGjN8yTEfMPUi+wdZfSMjwwIbYCyvWO7OkADUBwOg
8ScL6CLccPA6pxSM05FxAdhafFCa5gXaLcXAxAgSw2Y/PiAHTMyezAwLWBmCwbbmgldqVTJ4Am1P
Y4CduA5bsYUdcAL1awDtB4U4KO+C7BfY6QbMJw4MAmvcGd4g+RkEYGEAXv8NXRfJiuFz4twDW+Jm
AbQfW/iD0ksYML1knGL2UAAWGD+QzhywgdqvwACKa2fwOrYCBn9gKkBZ6Q8GIH8hr31ZiBSnoDQo
BL7PEFJmgeyfsNadYeFqBpQl6dgAzCaIrZDVcAHgvABZ74YvDWasQ6RBMaBKXOkPBmDpHkaDxBKA
EAZYBCFlGR8UEwKw0VrYvhtC9uMCJ4FOAzlmuJdxowA3YATGPjMXJA2hl92g+httHZtLfnJpbmpe
CTjt+QaDxIBC4MIExNaDyetZMHyx3ISy8WkUDEYAAFBLAQIUABQAAAAIAA0Zryiq3Gp7WRcAAACU
AAAJAAAAAAAAAAAAIAC2gQAAAABURC0xNC5kb2NQSwUGAAAAAAEAAQA3AAAAgBcAAAAA

------=_NextPart_000_0000_01C061B9.76580D60--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sat Dec  9 04:10:47 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA15966
	for <megaco-archive@LISTS.IETF.ORG>; Sat, 9 Dec 2000 04:10:47 -0500 (EST)
Received: from standards (47.234.32.16:2533) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC126B@standards.nortelnetworks.com>; Sat, 9 Dec 2000 3:51:23 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4129 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 9 Dec 2000 03:51:23 -0500
Received: from hindon.hss.co.in (202.54.26.202:55785) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC126A@standards.nortelnetworks.com>; Sat, 9 Dec 2000 3:51:21
          -0500
Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in
          (8.10.0/8.10.0) with SMTP id eB99AWh02971 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sat, 9 Dec 2000 14:40:33 +0530
          (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          652569B0.00313242 ; Sat, 9 Dec 2000 14:27:21 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <652569B0.003130A5.00@sandesh.hss.hns.com>
Date:         Sat, 9 Dec 2000 14:38:55 +0530
Reply-To: ssikri@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Sachin Sikri <ssikri@HSS.HNS.COM>
Subject:      Duplicate Hex. values
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi
In Annex G we have a Call Type Discrimination Package (ctype-0x0011).
Within this package the signal
V8bisSignal
SignalID: v8bs(0x0004) has a paramater as

V8bisSigname
ParameterID: V8bsn(0x0001)

Now the possible values for this parameter has two pairs of values having
duplicate hex. values

Mrdrl    (0x0006)
CReh   (0x0007)

CRel   (0x0006)
CRdi   (0x0007)

If anybody could tell me is this possible. If not then what should be the hex.
values for  this parameter

Regards
Sachin Sikri
Hughes Software System


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sat Dec  9 05:39:23 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09634
	for <megaco-archive@LISTS.IETF.ORG>; Sat, 9 Dec 2000 05:39:23 -0500 (EST)
Received: from standards (47.234.32.16:4165) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC12D8@standards.nortelnetworks.com>; Sat, 9 Dec 2000 5:20:11 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 4288 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 9 Dec 2000 05:20:11 -0500
Received: from hindon.hss.co.in (202.54.26.202:56985) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC12D7@standards.nortelnetworks.com>; Sat, 9 Dec 2000 5:20:10
          -0500
Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in
          (8.10.0/8.10.0) with SMTP id eB9AdLo04078 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Sat, 9 Dec 2000 16:09:21 +0530
          (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          652569B0.00395552 ; Sat, 9 Dec 2000 15:56:13 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <652569B0.00395471.00@sandesh.hss.hns.com>
Date:         Sat, 9 Dec 2000 16:07:49 +0530
Reply-To: ssikri@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Sachin Sikri <ssikri@HSS.HNS.COM>
Subject:      Errata :Duplicate Hex. values
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Please consider Annex F instead of Annex G as mentioned earlier

Sorry for the inconvinience........


---------------------- Forwarded by Sachin Sikri/HSS on 12/09/2000 03:59 PM
---------------------------


Sachin Sikri <ssikri@hss.hns.com> on 12/09/2000 02:38:55 PM

Please respond to ssikri@hss.hns.com

To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: Sachin Sikri/HSS)

Subject:  Duplicate Hex. values




Hi
In Annex G we have a Call Type Discrimination Package (ctype-0x0011).
Within this package the signal
V8bisSignal
SignalID: v8bs(0x0004) has a paramater as

V8bisSigname
ParameterID: V8bsn(0x0001)

Now the possible values for this parameter has two pairs of values having
duplicate hex. values

Mrdrl    (0x0006)
CReh   (0x0007)

CRel   (0x0006)
CRdi   (0x0007)

If anybody could tell me is this possible. If not then what should be the hex.
values for  this parameter

Regards
Sachin Sikri
Hughes Software System


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Dec 10 23:19:49 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA18277
	for <megaco-archive@LISTS.IETF.ORG>; Sun, 10 Dec 2000 23:19:48 -0500 (EST)
Received: from standards (47.234.32.16:2711) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC1898@standards.nortelnetworks.com>; 10 Dec 2000 23:00:11 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6284 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 10 Dec 2000 23:00:11 -0500
Received: from hindon.hss.co.in (202.54.26.202:36196) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC1897@standards.nortelnetworks.com>; 10 Dec 2000 23:00:09
          -0500
Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in
          (8.10.0/8.10.0) with SMTP id eBB4JOJ03917 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 11 Dec 2000 09:49:25
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          652569B2.00168A5E ; Mon, 11 Dec 2000 09:36:12 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <652569B2.00168902.00@sandesh.hss.hns.com>
Date:         Mon, 11 Dec 2000 09:42:09 +0530
Reply-To: chassija@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chanchal Hassija <chassija@HSS.HNS.COM>
Subject:      ToneGen...CPTGen
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hello All,

CPTGen package extends ToneGen package.

If MGC applies a signal - tonegen/playtone(toneid=dial tone), and the
termination has ToneGen as well as CPT gen loaded, should the MG invoke
CPTGEN/playtone{ toneid=dial tone}. Is this not invalid since ToneId=DialTone is
not a valid parameter for the Base-Package and hence MGC can't refer to what is
valid in extended package only, by using BasePackageId.

Thanks for your time

Chan....


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec 11 00:11:20 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA28898
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Dec 2000 00:11:19 -0500 (EST)
Received: from standards (47.234.32.16:4193) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC18C2@standards.nortelnetworks.com>; 10 Dec 2000 23:51:58 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6340 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 10 Dec 2000 23:51:58 -0500
Received: from hindon.hss.co.in (202.54.26.202:37825) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC18C1@standards.nortelnetworks.com>; 10 Dec 2000 23:41:53
          -0500
Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in
          (8.10.0/8.10.0) with SMTP id eBB519m06034 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 11 Dec 2000 10:31:09
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          652569B2.001C0BF9 ; Mon, 11 Dec 2000 10:17:58 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <652569B2.001A5B81.00@sandesh.hss.hns.com>
Date:         Mon, 11 Dec 2000 10:29:34 +0530
Reply-To: sidsharma@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Siddhartha Sharma <sidsharma@HSS.HNS.COM>
Subject:      Re: ServiceChange - Failover
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi Tom,
If standby MG has to issue a ServiceChange then what will be the
ServiceChangeMethod ? How MGC will now that this MG has taken over the failed MG
and how it will synchronize its state (if primary MG is not capable of sending
the ServiceChange)?

Is standby MG has to issue the ServiceChange with Disconnected as
ServiceChangeMethod, to inform the MGC to re-synchronize its state.

Regards,
Siddhartha Sharma




"Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM> on 12/08/2000
10:21:16 PM

Please respond to "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>

To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: Siddharth Sharma/HSS)

Subject:  Re: ServiceChange - Failover




If the active MG can send out a ServiceChange message, it should do so.
This makes the MGC aware that the MG is being replaced.  The standby MG has
to initiate the new control association in any event, so it will (also)
issue a ServiceChange.

> -----Original Message-----
> From: Chanchal Hassija [mailto:chassija@HSS.HNS.COM]
> Sent: Wednesday, December 06, 2000 3:18 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: [MEGACO] ServiceChange - Failover
>
>
> Hello All,
>
>
>
>       The scenario is one MGC and two MGs...one active and
> one standby. On
>       faliure of active MG, standby MG is taking over.
>
>       It is the responsibility of which MG to send the
> ServiceChange (failover
>       method and MG impending failure as the reason). As per
> 11.4 section in the
>       protocol document, it appears that it is the
> responsibilityof the active
>       MG(MG which is going down). But if Active MG is not
> capable of sending a
>       message to MGC, how shall MGC come to know that the
> standby MG is now
>       active MG.
>
>       Is it not better that the MG which gets active after
> switchover sends the
>       ServiceChange ?
>
>
>
> Thanks for your time
>
> Chan...
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec 11 01:52:23 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02138
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Dec 2000 01:52:23 -0500 (EST)
Received: from standards (47.234.32.16:2084) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC190D@standards.nortelnetworks.com>; Mon, 11 Dec 2000 1:32:55 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6430 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Dec 2000 01:32:55 -0500
Received: from zmers013 (47.124.1.40:49794) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC190C@standards.nortelnetworks.com>; Mon, 11 Dec 2000 1:32:45
          -0500
Received: from tlhuph12.elex.co.il (actually ertpg1e0.us.nortel.com) by
          zmers013; Mon, 11 Dec 2000 01:49:48 -0500
Received: from tmx100.elex.co.il (tmx100.elex.co.il [141.226.8.254]) by
          tlhuph12.elex.co.il (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id IAA26576
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 11 Dec 2000 08:50:06
          +0200 (IST)
Received: from tmofpc19 by tmx100.elex.co.il (8.8.8+Sun/SMI-SVR4) id IAA27727;
          Mon, 11 Dec 2000 08:50:05 +0200 (IST)
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_0094_01C0634F.238B1EA0"
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:  <009701c0633e$6074e690$ee0be28d@elex.co.il>
Date:         Mon, 11 Dec 2000 08:48:31 +0200
Reply-To: "Sherman, Nava [LOD:Telrad:SMTPPART]" <nava.sherman@TELRAD.CO.IL>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Sherman, Nava [LOD:Telrad:SMTPPART]" <nava.sherman@TELRAD.CO.IL>
Subject:      isdn access and MEGACO
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_0094_01C0634F.238B1EA0
Content-Type: text/plain;
        charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

Hi all,
for Implemening access gateway ISDN/MEGACO
1. what is the the packeges which the gateway need to support (in =
addition to (SIGTRAN and isdn packeges)).
2. what is the profile of such a gateway?
3. how does a call initiatied in such a gateway, I mean, if the Q931 is =
passed through the SIGTRAN,  why does the
gateway need to detect offhook, and digits etc.

Thank you,
Nava.

------=_NextPart_000_0094_01C0634F.238B1EA0
Content-Type: text/html;
        charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1255" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3D"Arial (Hebrew)" size=3D2>Hi all,</FONT></DIV>
<DIV><FONT face=3D"Arial (Hebrew)" size=3D2>for Implemening access =
gateway=20
ISDN/MEGACO</FONT></DIV>
<DIV><FONT face=3D"Arial (Hebrew)" size=3D2>1. what is the the packeges =
which the=20
gateway need to support (in addition to (SIGTRAN and isdn=20
packeges)).</FONT></DIV>
<DIV><FONT face=3D"Arial (Hebrew)" size=3D2>2. what is the profile of =
such a=20
gateway?</FONT></DIV>
<DIV><FONT face=3D"Arial (Hebrew)" size=3D2>3. how does a call =
initiatied in such a=20
gateway, I mean, if the Q931 is passed through the SIGTRAN,&nbsp; why =
does=20
the</FONT></DIV>
<DIV><FONT face=3D"Arial (Hebrew)" size=3D2>gateway need to detect =
offhook, and=20
digits etc.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Arial (Hebrew)" size=3D2>Thank you,</FONT></DIV>
<DIV><FONT face=3D"Arial (Hebrew)" =
size=3D2>Nava.</FONT></DIV></BODY></HTML>

------=_NextPart_000_0094_01C0634F.238B1EA0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec 11 02:00:01 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05250
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Dec 2000 02:00:01 -0500 (EST)
Received: from standards (47.234.32.16:2084) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC192C@standards.nortelnetworks.com>; Mon, 11 Dec 2000 1:40:38 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6473 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Dec 2000 01:40:37 -0500
Received: from hindon.hss.co.in (202.54.26.202:40960) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC192B@standards.nortelnetworks.com>; Mon, 11 Dec 2000
          1:40:34 -0500
Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in
          (8.10.0/8.10.0) with SMTP id eBB6xnd09726 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 11 Dec 2000 12:29:49
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          652569B2.0025343B ; Mon, 11 Dec 2000 12:16:22 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <652569B2.002532F2.00@sandesh.hss.hns.com>
Date:         Mon, 11 Dec 2000 12:22:19 +0530
Reply-To: chassija@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chanchal Hassija <chassija@HSS.HNS.COM>
Subject:      Re: Implementor's Guide change
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hello Christian / List

Could you please clarify the text given below.....

Thanks
Chan...





Chanchal Hassija <chassija@hss.hns.com> on 12/08/2000 04:36:09 PM

Please respond to chassija@hss.hns.com

To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
cc:    (bcc: Chanchal Hassija/HSS)

Subject:  Implementor's Guide change




Hello,

It was agreed upon sometime back in the mailingList that

In the reply to Audit Capabilities, we need to send only list of statisticsIds
(and not value) in the statistics descriptor. But as per ABNF grammar, the value
is not optional in Statistics descriptor.

Have we included this change in Implementor's Guide ?

Thanks for your time
Chan.....


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec 11 02:11:41 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA15420
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Dec 2000 02:11:41 -0500 (EST)
Received: from standards (47.234.32.16:2084) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC1943@standards.nortelnetworks.com>; Mon, 11 Dec 2000 1:52:15 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6504 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Dec 2000 01:52:14 -0500
Received: from hindon.hss.co.in (202.54.26.202:41196) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC1942@standards.nortelnetworks.com>; Mon, 11 Dec 2000
          1:52:12 -0500
Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in
          (8.10.0/8.10.0) with SMTP id eBB7BSM09995 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 11 Dec 2000 12:41:28
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          652569B2.00264D75 ; Mon, 11 Dec 2000 12:28:21 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <652569B2.00264D15.00@sandesh.hss.hns.com>
Date:         Mon, 11 Dec 2000 12:34:21 +0530
Reply-To: chassija@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chanchal Hassija <chassija@HSS.HNS.COM>
Subject:      Notify Command
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hello All,

ObservedEvent-Descriptor is a mandatory parameter in Notify command
Error-Desciptor is optional.
If MG needs to notify an error to MGC, but there is no event which was detected,
how does MG generate a Notify command ?

Thanks
Chan....


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec 11 06:34:06 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26298
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Dec 2000 06:34:05 -0500 (EST)
Received: from standards (47.234.32.16:4925) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC1A37@standards.nortelnetworks.com>; Mon, 11 Dec 2000 6:14:43 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 6817 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Dec 2000 06:14:42 -0500
Received: from ionicmicro.com (202.142.67.15:3609) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC1A2D@standards.nortelnetworks.com>; Mon, 11 Dec 2000
          6:04:41 -0500
Received: from keyoor98 by ionicmicro.com with SMTP (MDaemon.v3.0.0.R) for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 11 Dec 2000 17:04:32 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_00B0_01C06392.0A4D7F80"
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
X-MDaemon-Deliver-To: MEGACO@STANDARDS.NORTELNETWORKS.COM
X-Return-Path: keyoor@ionicmicro.com
X-MDRcpt-To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Message-ID:  <00b301c06363$f0be7660$a2b695cd@keyoor98>
Date:         Mon, 11 Dec 2000 16:47:25 +0530
Reply-To: keyoor@ionicmicro.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Keyoor <keyoor@ionicmicro.com>
Subject:      question regarding sdp parser
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_00B0_01C06392.0A4D7F80
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Good day all,
    I have one question on sdp parser.
    While in the design stage we found that parsing through lex and yacc =
the parser becomes non reentrant. So I left that concept and wrote the =
parser using plain C. Now I want to write parser using lex and yacc.
    Can anybody suggest that how do I make parser reentrant in lex and =
yacc?
    Or do I need to put syncronization mechanism in the caller who calls =
the parser?

Waiting for the reply.
keyoor
   =20

------=_NextPart_000_00B0_01C06392.0A4D7F80
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Good day all,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; I have one question =
on sdp=20
parser.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; While in the design =
stage we=20
found that parsing through lex and yacc the parser becomes non =
reentrant. So I=20
left that concept and wrote the parser using plain C. Now I want to =
write parser=20
using lex and yacc.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; Can anybody suggest =
that how do=20
I make parser reentrant&nbsp;in lex and yacc?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; Or do I need to put=20
syncronization mechanism in the caller who calls the =
parser?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Waiting for the reply.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>keyoor</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; =
</FONT></DIV></BODY></HTML>

------=_NextPart_000_00B0_01C06392.0A4D7F80--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec 11 09:59:10 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02623
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Dec 2000 09:59:09 -0500 (EST)
Received: from standards (47.234.32.16:1258) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC1B6D@standards.nortelnetworks.com>; Mon, 11 Dec 2000 9:39:36 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 7231 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Dec 2000 09:39:36 -0500
Received: from ns01.newbridge.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBC1B65@standards.nortelnetworks.com>; Mon, 11 Dec 2000 9:29:36
          -0500
Received: (from smtpd@localhost) by ns01.newbridge.com (8.9.2/8.9.2) id
          JAA19476 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 11 Dec 2000
          09:39:04 -0500 (EST)
Received: from portal1.newbridge.com(192.75.23.76),
          claiming to be "kanata-mh1.ca.newbridge.com" via SMTP by
          ns01.newbridge.com, id smtpdAAAixR2._; Mon Dec 11 09:38:58 2000
Received: from kanmail01.ca.newbridge.com by kanata-mh1.ca.newbridge.com with
          ESMTP for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Dec 2000
          09:34:01 -0500
Received: from alcatel.com ([138.120.45.48]) by kanmail01.ca.newbridge.com
          (Netscape Messaging Server 3.6)  with ESMTP id AAAA54 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 11 Dec 2000 09:33:59 -0500
X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------7ADCC513F354F2596268EE83"
Message-ID:  <3A34E5D7.92274941@alcatel.com>
Date:         Mon, 11 Dec 2000 09:33:59 -0500
Reply-To: Robert Zgraggen <robert.zgraggen@ALCATEL.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Robert Zgraggen, P. Eng." <robert.zgraggen@ALCATEL.COM>
Organization: Alcatel Carrier Internetworking Division (CID)
Subject:      How to unsubscribe fom this newsgroup
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.
--------------7ADCC513F354F2596268EE83
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

How do I unsubscribe from this newsgroup. It is certainly not very user friendly.

I sent an email to 'listserv@standards.nortelnetworks.com'
subject: megaco
body: unsubscribe megaco Robert Zgraggen


I also tried:
subject: unsubscribe megaco
body:


======

In both cases I am getting no useful feedback from the server (as you can see below)
to allow me to unsubscribe.

Your message is being returned to  you unprocessed because no command was found
in the  message body.  LISTSERV expects  commands in the  body of  the message,
rather than in the message subject, because some users have no control over the
contents of the "Subject:" field on outgoing messages.

> "L-Soft list server at Nortel IETF (1.8d)" wrote:
> >
> > > unsubscribe megaco Robert Zgraggen
> > Invalid option - "ROBERT". The valid options are GLobal, LOCal and NETWIDE
> > (minimum abbreviations shown in upper case).
> >
> > Summary of resource utilization
> > -------------------------------
> >  CPU time:        0.000 sec
> >  Overhead CPU:    0.000 sec
> >  CPU model:         400MHz Pentium II (256M)
> >  Job origin:      robert.zgraggen@ALCATEL.COM
--------------7ADCC513F354F2596268EE83
Content-Type: text/x-vcard; charset=us-ascii;
 name="robert.zgraggen.vcf"
Content-Description: Card for Robert Zgraggen, P. Eng.
Content-Disposition: attachment;
 filename="robert.zgraggen.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard
n:Zgraggen;Robert
tel;fax:(613) 599-2915
tel;work:(613)784-5485
x-mozilla-html:FALSE
org:Alcatel Carrier Internetworking Division (CID);Edge Data Networks
adr:;;600 March Road;Kanata;Ontario;K2K 2E6;Canada
version:2.1
email;internet:robert.zgraggen@alcatel.com
title:Software Engineer
x-mozilla-cpt:;-8304
fn:Robert Zgraggen, P.Eng.
end:vcard

--------------7ADCC513F354F2596268EE83--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec 11 11:24:36 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16122
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Dec 2000 11:24:32 -0500 (EST)
Received: from standards (47.234.32.16:4200) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC1BE6@standards.nortelnetworks.com>; Mon, 11 Dec 2000 11:04:58 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 7394 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Dec 2000 11:04:58 -0500
Received: from zrchs148 (47.100.129.12:62517) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC1BE1@standards.nortelnetworks.com>; Mon, 11 Dec 2000 10:54:58
          -0500
Received: from zrchb200.us.nortel.com (actually zrchb200) by zrchs148; Mon, 11
          Dec 2000 10:05:32 -0600
Received: from zrtpd00x.us.nortel.com ([47.140.202.32]) by
          zrchb200.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2652.39) id XNDSNCBV; Mon, 11 Dec 2000 10:12:52
          -0600
Received: from americasm01.nt.com (brtphe34.us.nortel.com [47.202.35.89]) by
          zrtpd00x.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2652.39) id YN94SV18; Mon, 11 Dec 2000 11:12:50
          -0500
X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.10.20 9000/778)
X-Accept-Language: en
References: <3A2D2732.894B17D3@usa.alcatel.com>
            <3A301413.B386DBB4@americasm01.nt.com>
            <3A30EBA9.A3DCDB98@usa.alcatel.com>
            <3A312D56.E2954351@americasm01.nt.com>
            <3A31447E.F6AC0947@usa.alcatel.com>
MIME-version: 1.0
Content-type: text/html; charset="us-ascii"
Content-transfer-encoding: 7bit
Message-ID:  <3A34FD01.C74499CA@americasm01.nt.com>
Date:         Mon, 11 Dec 2000 11:12:50 -0500
Reply-To: "Boyle, Kevin [NCRTP:3Z70:EXCH]" <kboyle@AMERICASM01.NT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Boyle, Kevin [NCRTP:3Z70:EXCH]" <kboyle@AMERICASM01.NT.COM>
Organization: Nortel Networks
Subject:      Re: [Fwd: ServiceChange corrections in Implementers Guide]
X-To:         Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body text="#000000" bgcolor="#FFFFFF" link="#0000FF" vlink="#FF0000" alink="#000088">
OK... it was my turn to misread this time.&nbsp; In the case of a MG that
is not actively communicating with MGC, I would say all messages except
a ServiceChange Restart would be ignored.&nbsp; If you choose to send error
messages to these kinds of things, you open the protocol to denial of service
attacks from unknown parties.&nbsp; An unregistered party could send an
overwhelming number of messages to a MGC, and the MGC would waste processing
resources trying to respond to every one of them.&nbsp; Even if the MGC
could keep up, now you've overwhelmed the network with message traffic
that will impact legitimate traffic.&nbsp; If the MGC throws these messages
away without response, then the traffic is minimized as much as possible
in these scenarios, and the MGC is not wasting processing time trying to
respond and keep up.
<p>Kevin
<p>Chuong Nguyen wrote:
<blockquote TYPE=CITE>You are missing the point.
<br>ServiceChange w/Forced or Graceful comes before ServiceChange w/Restart
in different
<br>messages.
<p>I am looking at error handling.
<br>MG did not send ServiceChange w/Restart but started sending ServiceChange
w/Forced/Graceful.
<br>&nbsp;
<br>&nbsp;
<p>Kevin Boyle wrote:
<blockquote TYPE=CITE>I would say that the MGC will process them like any
other communication from the MG: in the order of receipt.&nbsp; That is,
the MGC will finish processing the Restart, and then process the Forced/Graceful
appropriately.
<p>Kevin
<p>Chuong Nguyen wrote:
<blockquote TYPE=CITE>Ok I miss read the thing.
<p>I wanted to ask about Error code for MGC to send to MG if MG sends up
any command
<br>before MG does a ServiceChange with Restart.
<p>Said if MGC receives ServiceChange w/Forced/Graceful before receiving
ServiceChange
<br>w/Restart from MG, what should the MGC do:
<p>1) ignore the ServiceChange w/Forced/Graceful?
<br>2) send a ServiceChange reply w/an Error code of ????
<p>Thanks
<br>Chuong
<p>"Boyle, Kevin [NCRTP:3Z70:EXCH]" wrote:
<blockquote TYPE=CITE>Comments inline below [KJBII]
<p>Kevin
<p>Chuong Nguyen wrote:
<blockquote TYPE=CITE>Ops.&nbsp; One more point in Section 11. last paragraph
<p>"The <b>MG</b> shall issue error 505 - Command Received before Restart
Response."
<br>The "MG" should be "MGC".
<br>&nbsp;</blockquote>
[KJBII] Actually, the text is correct.&nbsp; This error indicates that
the MG received a command from the MGC before it received the MGC's response
to the ServiceChange Restart.</blockquote>

<blockquote TYPE=CITE>&nbsp;
<blockquote TYPE=CITE>&nbsp;
<br>This also brings up an interesting point.
<p>For sure error 505 applies to all commands before Restart but there
are exception for ServiceChange.
<p>For ServiceChange w/method Forced/Graceful, MGC should response w/error
505.
<br>For ServiceChange w/method HandOff or Failover, MGC should either accept
the
<br>registration or provide alternative MGC to try.
<p>Are the above assumption correct?
<br>&nbsp;</blockquote>
[KJBII] In these cases, the MG is in an active communication state with
the MGC, and then decides that it needs to go out of service.&nbsp; The
MGC may be in the process of sending a command while the MG is sending
the ServiceChange, and the commands "cross in the mail", so to speak.&nbsp;
In this case, the MG shouldn't reject the commands -- in fact, it should
continue to execute the commands if it can, until it recieves the MGC's
response to the Service Change, effectively taking the MG out of service.
<blockquote TYPE=CITE>&nbsp;
<br>Thanks
<br>Chuong
<p>Chuong Nguyen wrote:
<blockquote TYPE=CITE>Hi Christian
<p>I don't know if this was pointed out already.
<br>I am looking at H248_Implementors_guide_approved.zip.
<p>The change for Section 6.3&nbsp; Cold Start has the following:
<br>"If the MGC accepts the MG, it will send a Transaction Reply, with
the ServiceChangeMgcId
<br>set to itself."
<p>The change for Section 11.2 Cold Start has the following:
<br>"If the MGC accepts the MG's resignation, it sends a Transaction Reply
<b>not
</b>including
a
<br>ServiceChangeMgcId parameter."
<p>This 2 statements contradict each other.
<br>I think originally it was always "not" including a ServiceChangeMgcId
parameter.
<p>Also additional words might be added to clearly stated that
<br>"If the MG receives a Transaction Reply that includes a ServiceChangeMgcId
parameter, it sends
<br>a ServiceChange <b>w/a method of Restart </b>to the MGC specified in
the ServiceChangeMgcId."
<p>Otherwise someone might get confused and use ServiceChange w/a method
of handoff.
<p>Chuong</blockquote>
</blockquote>
</blockquote>

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

</body>
</html>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec 11 15:13:34 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA02160
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Dec 2000 15:13:34 -0500 (EST)
Received: from standards (47.234.32.16:3103) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC1CA3@standards.nortelnetworks.com>; Mon, 11 Dec 2000 14:53:56 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 7661 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Dec 2000 14:53:56 -0500
Received: from drawbridge.ascend.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBC1CA2@standards.nortelnetworks.com>; Mon, 11 Dec 2000 14:53:56
          -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 MAA08853 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 11 Dec 2000 12:03:42
          -0800 (PST)
Received: from russet.ascend.com by fw-ext.ascend.com via smtpd (for
          drawbridge.ascend.com [198.4.92.1]) with SMTP; 11 Dec 2000 20:11:50 UT
Received: from wopr.eng.ascend.com (wopr.eng.ascend.com [206.65.212.178]) by
          russet.ascend.com (8.9.1a/8.9.1) with ESMTP id MAA15888 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 11 Dec 2000 12:11:49
          -0800 (PST)
Received: from mastif.eng.ascend.com (mastif.eng.ascend.com [135.92.55.18]) by
          wopr.eng.ascend.com (8.9.1/8.9.1) with ESMTP id MAA27964 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 11 Dec 2000 12:11:49
          -0800 (PST)
Received: from sramannt-pc ([135.92.55.142]) by mastif.eng.ascend.com
          (8.8.8+Sun/8.8.8) with SMTP id PAA29786 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Mon, 11 Dec 2000 15:11:47
          -0500 (EST)
X-Sender: sraman@mastif.eng.ascend.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Message-ID:  <200012112011.PAA29786@mastif.eng.ascend.com>
Date:         Mon, 11 Dec 2000 15:12:23 -0500
Reply-To: Sankar Raman <Sankar.Raman@ASCEND.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Sankar Raman <Sankar.Raman@ASCEND.COM>
Subject:      Terminations out of svc
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

When a physical termination goes out of service,
does it go to the NULL context or stay in NULL context
(if it was already in NULL context) or the context
is not applicable for the termination ?

Thanks
Sankar Raman
Lucent Technologies.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec 11 19:07:10 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10077
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Dec 2000 19:07:09 -0500 (EST)
Received: from standards (47.234.32.16:1953) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC1D36@standards.nortelnetworks.com>; Mon, 11 Dec 2000 18:47:38 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 7866 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Dec 2000 18:47:38 -0500
Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC1D35@standards.nortelnetworks.com>; Mon, 11 Dec 2000
          18:47:37 -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 TAA22997
          for <megaco@standards.nortelnetworks.com>; Mon, 11 Dec 2000 19:05:33
          -0500 (EST)
Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com
          [135.17.42.35]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3)
          with ESMTP id TAA22993 for <megaco@standards.nortelnetworks.com>;
          Mon, 11 Dec 2000 19:05:32 -0500 (EST)
Received: by NJ7460EXCH002H with Internet Mail Service (5.5.2650.21) id
          <YCP3FKP5>; Mon, 11 Dec 2000 19:05:32 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <F38185D061EBD21185F10008C7F926CE04A61213@nj7460exch007u.ho.lucent.com>
Date:         Mon, 11 Dec 2000 19:05:27 -0500
Reply-To: "Griffeth, Nancy D (Nancy)" <nancyg@LUCENT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Griffeth, Nancy D (Nancy)" <nancyg@LUCENT.COM>
Subject:      questions about processing Commands
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Question 1 has to do with the order of processing descriptors:

In Section 7.2:
        The descriptors SHALL be processed in the order in which they
appear.

This may pose an insurmountable problem in processing an AuditDescriptor.
If, for example, an AuditDescriptor is the first
descriptor in a command, then the gateway returns the original values of the
requested descriptors.  If there are under-
or over-specified parameters in later descriptors, the gateway also chooses
values and returns a descriptor containing its choices.  This may require
two descriptors of the same kind in a command reply; I believe this is
prohibited.

To prevent this problem, I suggest processing the AuditDescriptor last,
regardless of where it appears
in a command.  That's the only position that prevents the problem when the
AuditDescriptor mentions descriptors that
appear in the command.  This would provide the gateway controller with the
values of the descriptors at the time the
command reply was created, which is intuitive.  If the MGC needs the
original values of the descriptors, it can send an
AuditValues command first.

There's a problem with this: use of this rule would prevent using the
AuditDescriptor in a Move to get mid-call statistics.
However, the order of processing the statistics piece of an AuditDescriptor
is dictated in Section 7.2.4 - the gateway
returns the statistics just prior to the move, regardless of the order of
the AuditDescriptor in the command.  Since this is a
primary purpose of the statistics option of the AuditDescriptor, I don't
imagine anyone would want to change it.  Also,
it doesn't create the above-mentioned problem.

So, how about auditing all descriptors except statistics last, and in a Move
command, audit the statistics just prior to
the move?

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

Question 2 has to do with what should be returned in the CommandReply when
parameters are over- or under-specified.

In Section 7.1.1 of the gateway control protocol standard document, it says:
        Whenever a parameter is underspecified or overspecified, the
descriptor containing the value chosen by the responder is included as
output from the command.
This can be read in two ways when there is a single property group (or SDP
entry):
1) The gateway should only return the values that it chose, omitting any
value supplied unambiguously
by the gateway controller; or
2) The gateway should return the entire descriptor, with the selected values
filled in to replace under- or over-specified
parameters.
Which is it?  The former is more efficient, but the latter is more
consistent with handling of multiple property groups
(or multiple SDP entries).
It's clear that if there are multiple property groups or SDP entries, option
1) would be ambiguous.  The spec is unambiguous that option 2 is the choice.

-----------------------------------------
Question 3 also addresses processing multiple property groups or SDP
entries, and under- or over-specified parameters:
The specification says:
        If ReserveGroup is true, the MG reserves the resources required to
support any of the requested property group alternatives that it can
currently support.  If ReserveValue is true, the MG reserves the resources
required to support any of the requested property value alternatives that it
can currently support.
Does "support" here refer only to the availability of resources, or to the
packages and properties supported?  If the latter,
does this mean that the messages "440 - unsupported or unknown package" and
"445 - no such property in this package"
would never be seen when reserveGroup and reserveValue are true?

Thanks for your time,

Nancy Griffeth


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec 11 20:32:47 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA22856
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Dec 2000 20:32:46 -0500 (EST)
Received: from standards (47.234.32.16:3513) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC1D77@standards.nortelnetworks.com>; Mon, 11 Dec 2000 20:13:21 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 7958 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Dec 2000 20:13:21 -0500
Received: from firewall.chttl.com.tw (gate.chttl.com.tw) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC1D76@standards.nortelnetworks.com>; Mon, 11 Dec 2000
          20:13:20 -0500
Received: from ms.chttl.com.tw (ms.tl.gov.tw. [10.144.2.104]) by
          firewall.chttl.com.tw (8.9.3/8.9.3) with ESMTP id JAA10768 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 12 Dec 2000 09:31:03
          +0800 (CST)
Received: from bigmab ([10.144.200.130]) by ms.chttl.com.tw (8.10.2/8.10.2)
          with SMTP id eBC1Zxv29598 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>;
          Tue, 12 Dec 2000 09:36:00 +0800 (CST)
References:  <28560036253BD41191A10000F8BCBD11030A5FAA@zcard00g.ca.nortel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="big5"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Message-ID:  <011701c063db$561cf5a0$82c8900a@chttl.com.tw>
Date:         Tue, 12 Dec 2000 09:31:52 +0800
Reply-To: "Lien, Yan Tsung" <jupy@MS.CHTTL.COM.TW>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Lien, Yan Tsung" <jupy@MS.CHTTL.COM.TW>
Subject:      What dose BOF(birds of a feather) mean?
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

What dose BOF(birds of a feather) mean?


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec 11 22:01:45 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA10949
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 11 Dec 2000 22:01:44 -0500 (EST)
Received: from standards (47.234.32.16:1492) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC1DAA@standards.nortelnetworks.com>; Mon, 11 Dec 2000 21:42:11 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8023 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 11 Dec 2000 21:42:11 -0500
Received: from cisco.com (jindo.cisco.com) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC1DA9@standards.nortelnetworks.com>; Mon, 11 Dec 2000 21:42:11
          -0500
Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by
          cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id
          TAA22615; Mon, 11 Dec 2000 19:00:06 -0800 (PST)
Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List
          Logging/CISCO.WS.1.2) id TAA13887; Mon, 11 Dec 2000 19:00:06 -0800
          (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
References: <28560036253BD41191A10000F8BCBD11030A5FAA@zcard00g.ca.nortel.com>
            <011701c063db$561cf5a0$82c8900a@chttl.com.tw>
X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid
X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4m<D]vnFJ>u!4x[/Z4t{V}~L]+Sk
        @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd
        bUcI'1!
Message-ID:  <14901.38069.825333.52068@thomasm-u1.cisco.com>
Date:         Mon, 11 Dec 2000 19:00:05 -0800
Reply-To: Michael Thomas <mat@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Michael Thomas <mat@CISCO.COM>
Subject:      What dose BOF(birds of a feather) mean?
X-To:         "Lien, Yan Tsung" <jupy@MS.CHTTL.COM.TW>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <011701c063db$561cf5a0$82c8900a@chttl.com.tw>
Content-Transfer-Encoding: 7bit

Lien, Yan Tsung writes:
 > What dose BOF(birds of a feather) mean?

   Ah, cultural imperialism at its best :-)

   There is an old quip that "birds of a feather
   flock together". Meaning birds of the same species
   stay in flocks together. BOF is a contraction
   of that, and roughly means "people interested in
   a class of problem that they think should be
   solved". In IETF context, it's a process to get
   the IESG to agree :-)

            Mike


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Dec 12 06:08:32 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07977
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 12 Dec 2000 06:08:31 -0500 (EST)
Received: from standards (47.234.32.16:3588) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC1E9E@standards.nortelnetworks.com>; Tue, 12 Dec 2000 5:48:53 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8330 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 12 Dec 2000 05:48:52 -0500
Received: from zmers013 (47.124.1.40:47663) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC1E9D@standards.nortelnetworks.com>; Tue, 12 Dec 2000 5:48:52
          -0500
Received: from tlhuph12.elex.co.il (actually ertpg1e0.us.nortel.com) by
          zmers013; Tue, 12 Dec 2000 06:06:34 -0500
Received: from tmx100.elex.co.il (tmx100.elex.co.il [141.226.8.254]) by
          tlhuph12.elex.co.il (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id NAA28702
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 12 Dec 2000 13:06:50
          +0200 (IST)
Received: from tmofpc19 by tmx100.elex.co.il (8.8.8+Sun/SMI-SVR4) id NAA00066;
          Tue, 12 Dec 2000 13:06:49 +0200 (IST)
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_00C0_01C0643C.4E6E7110"
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:  <00c301c0642b$8c38d500$ee0be28d@elex.co.il>
Date:         Tue, 12 Dec 2000 13:06:13 +0200
Reply-To: "Sherman, Nava [LOD:Telrad:SMTPPART]" <nava.sherman@TELRAD.CO.IL>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Sherman, Nava [LOD:Telrad:SMTPPART]" <nava.sherman@TELRAD.CO.IL>
Subject:      standard example
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_00C0_01C0643C.4E6E7110
Content-Type: text/plain;
        charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

Hi All!
in the example of the standard. after the exchange of servicechange =
request and reply the MGC sends the MG the=20
first modify command:
=20
MGC to MG1:

MEGACO/1 [123.123.123.4]:55555

Transaction =3D 9999 {

    Context =3D - {

        Modify =3D A4444 {

            Media { Stream =3D 1 {=20

                     LocalControl {

                         Mode =3D SendReceive,=20

                         tdmc/gain=3D2,  ; in dB,=20

                         tdmc/ec=3Don

                     },

                     Local {

v=3D0

c=3DIN IP4 $
m=3Daudio $ RTP/AVP 0

a=3Dfmtp:PCMU VAD=3DX-NNVAD ; special voice activity=20

                        ; detection algorithm

                     }

                 }

            },

            Events =3D 2222 {al/of}        =20

        }

    }

}

 my questions are:

=20

MG1 to MGC:

MEGACO/1 [124.124.124.222]:55555

Reply =3D 9999 {

   Context =3D - {Modify =3D A4444}

}

does an TDM connection have rtp properties? if it is what are their =
applicative meaning?

and if it does, why if it has choose option in the modify command the MG =
does not answer

its choice in the reply to the modify command?

Thanks.

Nava.


------=_NextPart_000_00C0_01C0643C.4E6E7110
Content-Type: text/html;
        charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1255" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi All!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>in the example of the standard. after =
the exchange=20
of servicechange request and reply the MGC sends the MG the =
</FONT></DIV>
<DIV><FONT face=3D"Arial (Hebrew)" size=3D2>first modify =
command:</FONT></DIV>
<DIV><FONT face=3D"Arial (Hebrew)" size=3D2>&nbsp;
<P class=3DStyle0><SPAN=20
style=3D"COLOR: black; FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">MGC =
to=20
MG1:<?xml:namespace prefix =3D o ns =3D =
"urn:schemas-microsoft-com:office:office"=20
/><o:p></o:p></SPAN></P>
<P class=3DStyle0><SPAN=20
style=3D"COLOR: black; FONT-FAMILY: 'Courier New'; FONT-SIZE: =
10pt">MEGACO/1=20
[123.123.123.4]:55555<o:p></o:p></SPAN></P>
<P class=3DStyle0><SPAN=20
style=3D"COLOR: black; FONT-FAMILY: 'Courier New'; FONT-SIZE: =
10pt">Transaction =3D=20
9999 {<o:p></o:p></SPAN></P>
<P class=3DStyle0><SPAN=20
style=3D"COLOR: black; FONT-FAMILY: 'Courier New'; FONT-SIZE: =
10pt"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>Context =3D -=20
{<o:p></o:p></SPAN></P>
<P class=3DStyle0><SPAN=20
style=3D"COLOR: black; FONT-FAMILY: 'Courier New'; FONT-SIZE: =
10pt"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>Modify =3D A4444 {<o:p></o:p></SPAN></P>
<P class=3DStyle0><SPAN=20
style=3D"COLOR: black; FONT-FAMILY: 'Courier New'; FONT-SIZE: =
10pt"><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>Media { Stream =3D 1 { <o:p></o:p></SPAN></P>
<P class=3DStyle0><SPAN=20
style=3D"COLOR: black; FONT-FAMILY: 'Courier New'; FONT-SIZE: =
10pt"><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>LocalControl {<o:p></o:p></SPAN></P>
<P class=3DStyle0><SPAN=20
style=3D"COLOR: black; FONT-FAMILY: 'Courier New'; FONT-SIZE: =
10pt"><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
</SPAN>Mode =3D SendReceive, <o:p></o:p></SPAN></P>
<P class=3DStyle0><SPAN=20
style=3D"COLOR: black; FONT-FAMILY: 'Courier New'; FONT-SIZE: =
10pt"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;</SPAN><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>tdmc/gain=3D2,<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>; =
in dB,=20
<o:p></o:p></SPAN></P>
<P class=3DStyle0><SPAN=20
style=3D"COLOR: black; FONT-FAMILY: 'Courier New'; FONT-SIZE: =
10pt"><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
</SPAN>tdmc/ec=3Don<o:p></o:p></SPAN></P>
<P class=3DStyle0><SPAN=20
style=3D"COLOR: black; FONT-FAMILY: 'Courier New'; FONT-SIZE: =
10pt"><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>},<o:p></o:p></SPAN></P>
<P class=3DStyle0><SPAN=20
style=3D"COLOR: black; FONT-FAMILY: 'Courier New'; FONT-SIZE: =
10pt"><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>Local {<o:p></o:p></SPAN></P>
<P class=3DStyle0><SPAN=20
style=3D"COLOR: black; FONT-FAMILY: 'Courier New'; FONT-SIZE: =
10pt">v=3D0<o:p></o:p></SPAN></P>
<P class=3DStyle0><SPAN style=3D"FONT-FAMILY: 'Courier New'; FONT-SIZE: =
10pt">c=3DIN=20
IP4 $<BR>m=3Daudio $ RTP/AVP 0<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-FAMILY: 'Courier New'; LAYOUT-GRID-MODE: =
line">a=3Dfmtp:PCMU=20
VAD=3DX-NNVAD ; special voice activity <o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-FAMILY: 'Courier New'; LAYOUT-GRID-MODE: line"><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>; detection algorithm</SPAN><SPAN=20
style=3D"COLOR: black; FONT-FAMILY: 'Courier =
New'"><o:p></o:p></SPAN></P>
<P class=3DStyle0><SPAN=20
style=3D"COLOR: black; FONT-FAMILY: 'Courier New'; FONT-SIZE: =
10pt"><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>}<o:p></o:p></SPAN></P>
<P class=3DStyle0><SPAN=20
style=3D"COLOR: black; FONT-FAMILY: 'Courier New'; FONT-SIZE: =
10pt"><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>}<o:p></o:p></SPAN></P>
<P class=3DStyle0><SPAN=20
style=3D"COLOR: black; FONT-FAMILY: 'Courier New'; FONT-SIZE: =
10pt"><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>},<o:p></o:p></SPAN></P>
<P class=3DStyle0><SPAN=20
style=3D"COLOR: black; FONT-FAMILY: 'Courier New'; FONT-SIZE: =
10pt"><SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>Events =3D 2222 {al/of}<SPAN=20
style=3D"mso-spacerun: =
yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN><o:p></o:p></SPAN></P>
<P class=3DStyle0><SPAN=20
style=3D"COLOR: black; FONT-FAMILY: 'Courier New'; FONT-SIZE: =
10pt"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN>}<o:p></o:p></SPAN></P>
<P class=3DStyle0><SPAN=20
style=3D"COLOR: black; FONT-FAMILY: 'Courier New'; FONT-SIZE: =
10pt"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp; =
</SPAN>}<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"COLOR: black; FONT-FAMILY: 'Courier New'">}</SPAN><SPAN=20
style=3D"FONT-FAMILY: 'Courier New'; LAYOUT-GRID-MODE: =
line"><o:p></o:p></SPAN></P>
<P class=3DMsoBodyText style=3D"MARGIN-BOTTOM: 0pt"><SPAN=20
style=3D"FONT-FAMILY: 'Courier New'">&nbsp;<FONT face=3D"Arial =
(Hebrew)">my=20
questions are:</FONT></SPAN></P>
<P class=3DMsoBodyText style=3D"MARGIN-BOTTOM: 0pt"><FONT =
face=3DArial><SPAN=20
style=3D"FONT-FAMILY: 'Courier New'">&nbsp;</P>
<P class=3DStyle0><SPAN=20
style=3D"COLOR: black; FONT-FAMILY: 'Courier New'; FONT-SIZE: 10pt">MG1 =
to=20
MGC:<o:p></o:p></SPAN></P>
<P class=3DStyle0><SPAN=20
style=3D"COLOR: black; FONT-FAMILY: 'Courier New'; FONT-SIZE: =
10pt">MEGACO/1=20
[124.124.124.222]:55555<o:p></o:p></SPAN></P>
<P class=3DStyle0><SPAN=20
style=3D"COLOR: black; FONT-FAMILY: 'Courier New'; FONT-SIZE: =
10pt">Reply =3D 9999=20
{<o:p></o:p></SPAN></P>
<P class=3DStyle0><SPAN=20
style=3D"COLOR: black; FONT-FAMILY: 'Courier New'; FONT-SIZE: =
10pt"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>Context =3D - {Modify =
=3D=20
A4444}<o:p></o:p></SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"COLOR: black; FONT-FAMILY: 'Courier =
New'">}<o:p></o:p></SPAN></P></SPAN></FONT>
<P class=3DMsoBodyText style=3D"MARGIN-BOTTOM: 0pt"><FONT=20
face=3D"Arial (Hebrew)"><SPAN style=3D"FONT-FAMILY: 'Courier New'">does =
an TDM=20
connection have rtp properties? if it is what are their applicative=20
meaning?</SPAN></FONT></P>
<P class=3DMsoBodyText style=3D"MARGIN-BOTTOM: 0pt"><FONT=20
face=3D"Arial (Hebrew)"><SPAN style=3D"FONT-FAMILY: 'Courier New'">and =
if it does,=20
why if it has choose option in the modify command the MG does not=20
answer</SPAN></FONT></P>
<P class=3DMsoBodyText style=3D"MARGIN-BOTTOM: 0pt"><FONT=20
face=3D"Arial (Hebrew)"><SPAN style=3D"FONT-FAMILY: 'Courier New'">its =
choice in the=20
reply to the modify command?</SPAN></FONT></P>
<P class=3DMsoBodyText style=3D"MARGIN-BOTTOM: 0pt"><FONT=20
face=3D"Courier New (Hebrew)">Thanks.</FONT></P>
<P class=3DMsoBodyText style=3D"MARGIN-BOTTOM: 0pt"><FONT=20
face=3D"Courier New =
(Hebrew)">Nava.</FONT></P></FONT></DIV></BODY></HTML>

------=_NextPart_000_00C0_01C0643C.4E6E7110--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Dec 12 09:51:31 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03920
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 12 Dec 2000 09:51:30 -0500 (EST)
Received: from standards (47.234.32.16:1158) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC1F71@standards.nortelnetworks.com>; Tue, 12 Dec 2000 9:31:26 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8614 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 12 Dec 2000 09:31:25 -0500
Received: from netmail2.alcatel.com (mail2.alcatel.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC1F69@standards.nortelnetworks.com>; Tue, 12 Dec 2000
          9:21:25 -0500
Received: from relay1.usa.alcatel.com (relay1.usa.alcatel.com [143.209.238.6])
          by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id IAA26665 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 12 Dec 2000 08:39:20
          -0600 (CST)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by
          relay1.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id IAA25567 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 12 Dec 2000 08:39:18
          -0600 (CST)
Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com
          [143.209.151.53]) by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP
          id eBCEcvd11839 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 12
          Dec 2000 08:38:57 -0600 (CST)
Received: from usa.alcatel.com (localhost [127.0.0.1]) by
          sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id
          eBCEcv002965 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 12 Dec
          2000 08:38:57 -0600 (CST)
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <3A2D2732.894B17D3@usa.alcatel.com>
            <3A301413.B386DBB4@americasm01.nt.com>
            <3A30EBA9.A3DCDB98@usa.alcatel.com>
            <3A312D56.E2954351@americasm01.nt.com>
            <3A31447E.F6AC0947@usa.alcatel.com>
            <3A34FD01.C74499CA@americasm01.nt.com>
Content-Type: multipart/alternative;
              boundary="------------AE9D2CE549740796273080C5"
Message-ID:  <3A363880.3462E9D9@usa.alcatel.com>
Date:         Tue, 12 Dec 2000 08:38:56 -0600
Reply-To: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Subject:      Re: [Fwd: ServiceChange corrections in Implementers Guide]
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

Based on your line of reasoning, wouldn't it be the same defensive
stragtegy for MG to ignore
commands from MGC if the MG has not established an association w/the
MGC.

That is MG would not Reply w/any error code to commands from MGC if
MG has not finished registering
w/MGC (or registered w/MGC) to avoid "denial of service attachs from
unknown parties."

Chuong


"Boyle, Kevin [NCRTP:3Z70:EXCH]" wrote:

> OK... it was my turn to misread this time.  In the case of a MG that
> is not actively communicating with MGC, I would say all messages
> except a ServiceChange Restart would be ignored.  If you choose to
> send error messages to these kinds of things, you open the protocol to
> denial of service attacks from unknown parties.  An unregistered party
> could send an overwhelming number of messages to a MGC, and the MGC
> would waste processing resources trying to respond to every one of
> them.  Even if the MGC could keep up, now you've overwhelmed the
> network with message traffic that will impact legitimate traffic.  If
> the MGC throws these messages away without response, then the traffic
> is minimized as much as possible in these scenarios, and the MGC is
> not wasting processing time trying to respond and keep up.
>
> Kevin
>
> Chuong Nguyen wrote:
>
>> You are missing the point.
>> ServiceChange w/Forced or Graceful comes before ServiceChange
>> w/Restart in different
>> messages.
>>
>> I am looking at error handling.
>> MG did not send ServiceChange w/Restart but started sending
>> ServiceChange w/Forced/Graceful.
>>
>>
>>
>> Kevin Boyle wrote:
>>
>> > I would say that the MGC will process them like any other
>> > communication from the MG: in the order of receipt.  That is, the
>> > MGC will finish processing the Restart, and then process the
>> > Forced/Graceful appropriately.
>> >
>> > Kevin
>> >
>> > Chuong Nguyen wrote:
>> >
>> >>  Ok I miss read the thing.
>> >>
>> >>  I wanted to ask about Error code for MGC to send to MG if MG
>> >>  sends up any command
>> >>  before MG does a ServiceChange with Restart.
>> >>
>> >>  Said if MGC receives ServiceChange w/Forced/Graceful before
>> >>  receiving ServiceChange
>> >>  w/Restart from MG, what should the MGC do:
>> >>
>> >>  1) ignore the ServiceChange w/Forced/Graceful?
>> >>  2) send a ServiceChange reply w/an Error code of ????
>> >>
>> >>  Thanks
>> >>  Chuong
>> >>
>> >>  "Boyle, Kevin [NCRTP:3Z70:EXCH]" wrote:
>> >>
>> >> > Comments inline below [KJBII]
>> >> >
>> >> > Kevin
>> >> >
>> >> > Chuong Nguyen wrote:
>> >> >
>> >> >>  Ops.  One more point in Section 11. last paragraph
>> >> >>
>> >> >>  "The MG shall issue error 505 - Command Received before
>> >> >>  Restart Response."
>> >> >>  The "MG" should be "MGC".
>> >> >>
>> >> >
>> >> > [KJBII] Actually, the text is correct.  This error indicates
>> >> > that the MG received a command from the MGC before it received
>> >> > the MGC's response to the ServiceChange Restart.
>> >>
>> >> >
>> >> >
>> >> >>
>> >> >>  This also brings up an interesting point.
>> >> >>
>> >> >>  For sure error 505 applies to all commands before Restart but
>> >> >>  there are exception for ServiceChange.
>> >> >>
>> >> >>  For ServiceChange w/method Forced/Graceful, MGC should
>> >> >>  response w/error 505.
>> >> >>  For ServiceChange w/method HandOff or Failover, MGC should
>> >> >>  either accept the
>> >> >>  registration or provide alternative MGC to try.
>> >> >>
>> >> >>  Are the above assumption correct?
>> >> >>
>> >> >
>> >> > [KJBII] In these cases, the MG is in an active communication
>> >> > state with the MGC, and then decides that it needs to go out of
>> >> > service.  The MGC may be in the process of sending a command
>> >> > while the MG is sending the ServiceChange, and the commands
>> >> > "cross in the mail", so to speak.  In this case, the MG
>> >> > shouldn't reject the commands -- in fact, it should continue to
>> >> > execute the commands if it can, until it recieves the MGC's
>> >> > response to the Service Change, effectively taking the MG out
>> >> > of service.
>> >> >
>> >> >>
>> >> >>  Thanks
>> >> >>  Chuong
>> >> >>
>> >> >>  Chuong Nguyen wrote:
>> >> >>
>> >> >> > Hi Christian
>> >> >> >
>> >> >> > I don't know if this was pointed out already.
>> >> >> > I am looking at H248_Implementors_guide_approved.zip.
>> >> >> >
>> >> >> > The change for Section 6.3  Cold Start has the following:
>> >> >> > "If the MGC accepts the MG, it will send a Transaction
>> >> >> > Reply, with the ServiceChangeMgcId
>> >> >> > set to itself."
>> >> >> >
>> >> >> > The change for Section 11.2 Cold Start has the following:
>> >> >> > "If the MGC accepts the MG's resignation, it sends a
>> >> >> > Transaction Reply not including a
>> >> >> > ServiceChangeMgcId parameter."
>> >> >> >
>> >> >> > This 2 statements contradict each other.
>> >> >> > I think originally it was always "not" including a
>> >> >> > ServiceChangeMgcId parameter.
>> >> >> >
>> >> >> > Also additional words might be added to clearly stated that
>> >> >> > "If the MG receives a Transaction Reply that includes a
>> >> >> > ServiceChangeMgcId parameter, it sends
>> >> >> > a ServiceChange w/a method of Restart to the MGC specified
>> >> >> > in the ServiceChangeMgcId."
>> >> >> >
>> >> >> > Otherwise someone might get confused and use ServiceChange
>> >> >> > w/a method of handoff.
>> >> >> >
>> >> >> > Chuong
>> >> >>
>> >>  --
>> >>    Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>> >>    1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>> >>    **** The opinions expressed are not those of Alcatel USA, Inc ****
>> >>
--
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****



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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body text="#000000" bgcolor="#FFFFFF" link="#0000FF" vlink="#FF0000" alink="#000088">
Based on your line of reasoning, wouldn't it be the same defensive stragtegy
for MG to ignore
<br>commands from MGC if the MG has not established an association w/the
MGC.
<p>That is MG would not Reply w/any error code to commands from MGC if
MG&nbsp;has not finished registering
<br>w/MGC (or registered w/MGC) to avoid "denial of service attachs from
unknown parties."
<p>Chuong
<br>&nbsp;
<p>"Boyle, Kevin [NCRTP:3Z70:EXCH]" wrote:
<blockquote TYPE=CITE>OK... it was my turn to misread this time.&nbsp;
In the case of a MG that is not actively communicating with MGC, I would
say all messages except a ServiceChange Restart would be ignored.&nbsp;
If you choose to send error messages to these kinds of things, you open
the protocol to denial of service attacks from unknown parties.&nbsp; An
unregistered party could send an overwhelming number of messages to a MGC,
and the MGC would waste processing resources trying to respond to every
one of them.&nbsp; Even if the MGC could keep up, now you've overwhelmed
the network with message traffic that will impact legitimate traffic.&nbsp;
If the MGC throws these messages away without response, then the traffic
is minimized as much as possible in these scenarios, and the MGC is not
wasting processing time trying to respond and keep up.
<p>Kevin
<p>Chuong Nguyen wrote:
<blockquote TYPE=CITE>You are missing the point.
<br>ServiceChange w/Forced or Graceful comes before ServiceChange w/Restart
in different
<br>messages.
<p>I am looking at error handling.
<br>MG did not send ServiceChange w/Restart but started sending ServiceChange
w/Forced/Graceful.
<br>&nbsp;
<br>&nbsp;
<p>Kevin Boyle wrote:
<blockquote TYPE=CITE>I would say that the MGC will process them like any
other communication from the MG: in the order of receipt.&nbsp; That is,
the MGC will finish processing the Restart, and then process the Forced/Graceful
appropriately.
<p>Kevin
<p>Chuong Nguyen wrote:
<blockquote TYPE=CITE>Ok I miss read the thing.
<p>I wanted to ask about Error code for MGC to send to MG if MG sends up
any command
<br>before MG does a ServiceChange with Restart.
<p>Said if MGC receives ServiceChange w/Forced/Graceful before receiving
ServiceChange
<br>w/Restart from MG, what should the MGC do:
<p>1) ignore the ServiceChange w/Forced/Graceful?
<br>2) send a ServiceChange reply w/an Error code of ????
<p>Thanks
<br>Chuong
<p>"Boyle, Kevin [NCRTP:3Z70:EXCH]" wrote:
<blockquote TYPE=CITE>Comments inline below [KJBII]
<p>Kevin
<p>Chuong Nguyen wrote:
<blockquote TYPE=CITE>Ops.&nbsp; One more point in Section 11. last paragraph
<p>"The <b>MG</b> shall issue error 505 - Command Received before Restart
Response."
<br>The "MG" should be "MGC".
<br>&nbsp;</blockquote>
[KJBII] Actually, the text is correct.&nbsp; This error indicates that
the MG received a command from the MGC before it received the MGC's response
to the ServiceChange Restart.</blockquote>

<blockquote TYPE=CITE>&nbsp;
<blockquote TYPE=CITE>&nbsp;
<br>This also brings up an interesting point.
<p>For sure error 505 applies to all commands before Restart but there
are exception for ServiceChange.
<p>For ServiceChange w/method Forced/Graceful, MGC should response w/error
505.
<br>For ServiceChange w/method HandOff or Failover, MGC should either accept
the
<br>registration or provide alternative MGC to try.
<p>Are the above assumption correct?
<br>&nbsp;</blockquote>
[KJBII] In these cases, the MG is in an active communication state with
the MGC, and then decides that it needs to go out of service.&nbsp; The
MGC may be in the process of sending a command while the MG is sending
the ServiceChange, and the commands "cross in the mail", so to speak.&nbsp;
In this case, the MG shouldn't reject the commands -- in fact, it should
continue to execute the commands if it can, until it recieves the MGC's
response to the Service Change, effectively taking the MG out of service.
<blockquote TYPE=CITE>&nbsp;
<br>Thanks
<br>Chuong
<p>Chuong Nguyen wrote:
<blockquote TYPE=CITE>Hi Christian
<p>I don't know if this was pointed out already.
<br>I am looking at H248_Implementors_guide_approved.zip.
<p>The change for Section 6.3&nbsp; Cold Start has the following:
<br>"If the MGC accepts the MG, it will send a Transaction Reply, with
the ServiceChangeMgcId
<br>set to itself."
<p>The change for Section 11.2 Cold Start has the following:
<br>"If the MGC accepts the MG's resignation, it sends a Transaction Reply
<b>not
</b>including
a
<br>ServiceChangeMgcId parameter."
<p>This 2 statements contradict each other.
<br>I think originally it was always "not" including a ServiceChangeMgcId
parameter.
<p>Also additional words might be added to clearly stated that
<br>"If the MG receives a Transaction Reply that includes a ServiceChangeMgcId
parameter, it sends
<br>a ServiceChange <b>w/a method of Restart </b>to the MGC specified in
the ServiceChangeMgcId."
<p>Otherwise someone might get confused and use ServiceChange w/a method
of handoff.
<p>Chuong</blockquote>
</blockquote>
</blockquote>

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

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

--------------AE9D2CE549740796273080C5--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Dec 12 11:02:09 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12122
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 12 Dec 2000 11:02:08 -0500 (EST)
Received: from standards (47.234.32.16:1158) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC1FB2@standards.nortelnetworks.com>; Tue, 12 Dec 2000 10:42:25 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8698 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 12 Dec 2000 10:42:25 -0500
Received: from netmail2.alcatel.com (mail2.alcatel.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC1FAA@standards.nortelnetworks.com>; Tue, 12 Dec 2000
          10:32:25 -0500
Received: from relay2.usa.alcatel.com (relay2.usa.alcatel.com [143.209.238.7])
          by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id JAA07693; Tue, 12
          Dec 2000 09:50:19 -0600 (CST)
Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by
          relay2.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id JAA05047; Tue, 12
          Dec 2000 09:50:18 -0600 (CST)
Received: from sun3144.ssd.usa.alcatel.com (sun3144.ssd.usa.alcatel.com
          [143.209.151.53]) by ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP
          id eBCFnvd20685; Tue, 12 Dec 2000 09:49:57 -0600 (CST)
Received: from usa.alcatel.com (localhost [127.0.0.1]) by
          sun3144.ssd.usa.alcatel.com (8.11.1/8.11.1) with ESMTP id
          eBCFnv002993; Tue, 12 Dec 2000 09:49:57 -0600 (CST)
X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <28560036253BD41191A10000F8BCBD110312A49E@zcard00g.ca.nortel.com>
Content-Type: multipart/alternative;
              boundary="------------9DA693BB7BEFB8FAEF3D238B"
Message-ID:  <3A364924.7CA34118@usa.alcatel.com>
Date:         Tue, 12 Dec 2000 09:49:57 -0600
Reply-To: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
Subject:      Re: Modification of event and sig parameter ASN.1 syntax
X-To:         "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

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

So are you going to suggest at the meeting that the requirement that
MGC supports both text and
binary encoding be removed?

If no, the implementation for MGC would be too complicated.
Does anybody out there plan to provide an MGC that does both text and binary
encoding?

Thanks
Chuong



"Taylor, Tom-PT [NORSE:B901:EXCH]" wrote:

> MGC 2000 was a conference I attended last month.  What I was saying was that
> by specifying two different encodings we have in effect created two
> different protocols: MGCs of one persuasion won't talk to MGs of the other.
> It's unfair of me to try to turn the clock back, but the scarcity of
> binary-encoded implementations up to now gave me the very faint hope that
> those wanting to do binary could be persuaded to do text instead.
>
> -----Original Message-----
> From: Chuong Nguyen [mailto:Chuong.Nguyen@USA.ALCATEL.COM]
> Sent: Thursday, December 07, 2000 3:09 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: [MEGACO] Modification of event and sig parameter ASN.1 syntax
>
> Tom
>
> Are you suggesting that for the interoperability testing we stick to just
> text implementations or
> from now on all implementations of Megaco should be in text encoded?
>
> Has anyone implemented an MGC that supports both text and binary?
>
> Thanks
> Chuong
>
> Tom Taylor wrote:
>
> Do I get the impression that the ASN.1 version of Megaco is only
> half-defined and you want to finish the job?  I'll remark that the
> existence of both binary and text-encoded versions was deemed to be a major
> threat to interoperability at MGC 2000.  I suppose
> it's way too late now to try to persuade people to stick to text
> implementations?
>
> Tom Taylor
>
> --
>
>   Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
>
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>
>   **** The opinions expressed are not those of Alcatel USA, Inc ****

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



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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
So are you going to suggest at the meeting that the requirement that MGC&nbsp;supports
both text and
<br>binary encoding be removed?
<p>If no, the implementation for MGC would be too complicated.
<br>Does anybody out there plan to provide an MGC&nbsp;that does both text
and binary encoding?
<p>Thanks
<br>Chuong
<br>&nbsp;
<br>&nbsp;
<p>"Taylor, Tom-PT [NORSE:B901:EXCH]" wrote:
<blockquote TYPE=CITE>MGC 2000 was a conference I attended last month.&nbsp;
What I was saying was that
<br>by specifying two different encodings we have in effect created two
<br>different protocols: MGCs of one persuasion won't talk to MGs of the
other.
<br>It's unfair of me to try to turn the clock back, but the scarcity of
<br>binary-encoded implementations up to now gave me the very faint hope
that
<br>those wanting to do binary could be persuaded to do text instead.
<p>-----Original Message-----
<br>From: Chuong Nguyen [<a href="mailto:Chuong.Nguyen@USA.ALCATEL.COM">mailto:Chuong.Nguyen@USA.ALCATEL.COM</a>]
<br>Sent: Thursday, December 07, 2000 3:09 PM
<br>To: MEGACO@STANDARDS.NORTELNETWORKS.COM
<br>Subject: Re: [MEGACO] Modification of event and sig parameter ASN.1
syntax
<p>Tom
<p>Are you suggesting that for the interoperability testing we stick to
just
<br>text implementations or
<br>from now on all implementations of Megaco should be in text encoded?
<p>Has anyone implemented an MGC that supports both text and binary?
<p>Thanks
<br>Chuong
<p>Tom Taylor wrote:
<p>Do I get the impression that the ASN.1 version of Megaco is only
<br>half-defined and you want to finish the job?&nbsp; I'll remark that
the
<br>existence of both binary and text-encoded versions was deemed to be
a major
<br>threat to interoperability at MGC 2000.&nbsp; I suppose
<br>it's way too late now to try to persuade people to stick to text
<br>implementations?
<p>Tom Taylor
<p>--
<p>&nbsp; Alcatel USA, Inc&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Internet: Chuong.Nguyen@usa.alcatel.com
<p>&nbsp; 1000 Coit Road Plano, Texas 75075&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Phone:&nbsp;&nbsp;&nbsp; (972) 519-4613
<p>&nbsp; **** The opinions expressed are not those of Alcatel USA, Inc
****</blockquote>

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

--------------9DA693BB7BEFB8FAEF3D238B--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Dec 12 13:55:02 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19814
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 12 Dec 2000 13:55:01 -0500 (EST)
Received: from standards (47.234.32.16:3994) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2080@standards.nortelnetworks.com>; Tue, 12 Dec 2000 13:35:15 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 8964 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 12 Dec 2000 13:35:15 -0500
Received: from zmers013 (47.124.1.40:50572) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC2078@standards.nortelnetworks.com>; Tue, 12 Dec 2000 13:25:15
          -0500
Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by zmers013;
          Tue, 12 Dec 2000 13:42:41 -0500
Received: from zrtpd004.us.nortel.com (actually zrtpd004) by
          ertpg14e1.nortelnetworks.com; Tue, 12 Dec 2000 13:30:47 -0500
Received: from zrtpd00x.us.nortel.com ([47.140.202.32]) by
          zrtpd004.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2652.39) id YMLK83XX; Tue, 12 Dec 2000 13:30:45
          -0500
Received: from americasm01.nt.com (brtphe34.us.nortel.com [47.202.35.89]) by
          zrtpd00x.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2652.39) id YN94S5ZD; Tue, 12 Dec 2000 13:30:42
          -0500
X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.10.20 9000/778)
X-Accept-Language: en
MIME-Version: 1.0
References: <3A2D2732.894B17D3@usa.alcatel.com>
            <3A301413.B386DBB4@americasm01.nt.com>
            <3A30EBA9.A3DCDB98@usa.alcatel.com>
            <3A312D56.E2954351@americasm01.nt.com>
            <3A31447E.F6AC0947@usa.alcatel.com>
            <3A34FD01.C74499CA@americasm01.nt.com>
            <3A363880.3462E9D9@usa.alcatel.com>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3A366ED3.C1B3CD7F@americasm01.nt.com>
Date:         Tue, 12 Dec 2000 13:30:43 -0500
Reply-To: "Boyle, Kevin [NCRTP:3Z70:EXCH]" <kboyle@AMERICASM01.NT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Boyle, Kevin [NCRTP:3Z70:EXCH]" <kboyle@AMERICASM01.NT.COM>
Organization: Nortel Networks
Subject:      Re: [Fwd: ServiceChange corrections in Implementers Guide]
X-To:         Chuong Nguyen <Chuong.Nguyen@USA.ALCATEL.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body text="#000000" bgcolor="#FFFFFF" link="#0000FF" vlink="#FF0000" alink="#000088">
Based on the fact that the MG initiates the ServiceChange, the MGC must
be a known entity.&nbsp; Therefore, commands issued from that entity should
be responded to with an error.&nbsp; Take the following example for instance:
<p>The MG sends the ServiceChange to the MGC.
<br>The MGC responds, but due to congestion, the reply is delayed.
<br>In the meantime, the MGC starts sending commands to the MG.
<br>The commands arrive before the ServiceChange replay.
<p>The MGC needs to know that the MG was not able to execute the commands,
and needs to take further action.
<p>However, you do bring up a good point: If a MG recieves commands from
an entity to which MG did NOT send a ServiceChange, those commands should
be silently discarded.
<p>Kevin
<p>Chuong Nguyen wrote:
<blockquote TYPE=CITE>Based on your line of reasoning, wouldn't it be the
same defensive stragtegy for MG to ignore
<br>commands from MGC if the MG has not established an association w/the
MGC.
<p>That is MG would not Reply w/any error code to commands from MGC if
MG has not finished registering
<br>w/MGC (or registered w/MGC) to avoid "denial of service attachs from
unknown parties."
<p>Chuong
<br>&nbsp;
<p>"Boyle, Kevin [NCRTP:3Z70:EXCH]" wrote:
<blockquote TYPE=CITE>OK... it was my turn to misread this time.&nbsp;
In the case of a MG that is not actively communicating with MGC, I would
say all messages except a ServiceChange Restart would be ignored.&nbsp;
If you choose to send error messages to these kinds of things, you open
the protocol to denial of service attacks from unknown parties.&nbsp; An
unregistered party could send an overwhelming number of messages to a MGC,
and the MGC would waste processing resources trying to respond to every
one of them.&nbsp; Even if the MGC could keep up, now you've overwhelmed
the network with message traffic that will impact legitimate traffic.&nbsp;
If the MGC throws these messages away without response, then the traffic
is minimized as much as possible in these scenarios, and the MGC is not
wasting processing time trying to respond and keep up.
<p>Kevin
<p>Chuong Nguyen wrote:
<blockquote TYPE=CITE>You are missing the point.
<br>ServiceChange w/Forced or Graceful comes before ServiceChange w/Restart
in different
<br>messages.
<p>I am looking at error handling.
<br>MG did not send ServiceChange w/Restart but started sending ServiceChange
w/Forced/Graceful.
<br>&nbsp;
<br>&nbsp;
<p>Kevin Boyle wrote:
<blockquote TYPE=CITE>I would say that the MGC will process them like any
other communication from the MG: in the order of receipt.&nbsp; That is,
the MGC will finish processing the Restart, and then process the Forced/Graceful
appropriately.
<p>Kevin
<p>Chuong Nguyen wrote:
<blockquote TYPE=CITE>Ok I miss read the thing.
<p>I wanted to ask about Error code for MGC to send to MG if MG sends up
any command
<br>before MG does a ServiceChange with Restart.
<p>Said if MGC receives ServiceChange w/Forced/Graceful before receiving
ServiceChange
<br>w/Restart from MG, what should the MGC do:
<p>1) ignore the ServiceChange w/Forced/Graceful?
<br>2) send a ServiceChange reply w/an Error code of ????
<p>Thanks
<br>Chuong
<p>"Boyle, Kevin [NCRTP:3Z70:EXCH]" wrote:
<blockquote TYPE=CITE>Comments inline below [KJBII]
<p>Kevin
<p>Chuong Nguyen wrote:
<blockquote TYPE=CITE>Ops.&nbsp; One more point in Section 11. last paragraph
<p>"The <b>MG</b> shall issue error 505 - Command Received before Restart
Response."
<br>The "MG" should be "MGC".
<br>&nbsp;</blockquote>
[KJBII] Actually, the text is correct.&nbsp; This error indicates that
the MG received a command from the MGC before it received the MGC's response
to the ServiceChange Restart.</blockquote>

<blockquote TYPE=CITE>&nbsp;
<blockquote TYPE=CITE>&nbsp;
<br>This also brings up an interesting point.
<p>For sure error 505 applies to all commands before Restart but there
are exception for ServiceChange.
<p>For ServiceChange w/method Forced/Graceful, MGC should response w/error
505.
<br>For ServiceChange w/method HandOff or Failover, MGC should either accept
the
<br>registration or provide alternative MGC to try.
<p>Are the above assumption correct?
<br>&nbsp;</blockquote>
[KJBII] In these cases, the MG is in an active communication state with
the MGC, and then decides that it needs to go out of service.&nbsp; The
MGC may be in the process of sending a command while the MG is sending
the ServiceChange, and the commands "cross in the mail", so to speak.&nbsp;
In this case, the MG shouldn't reject the commands -- in fact, it should
continue to execute the commands if it can, until it recieves the MGC's
response to the Service Change, effectively taking the MG out of service.
<blockquote TYPE=CITE>&nbsp;
<br>Thanks
<br>Chuong
<p>Chuong Nguyen wrote:
<blockquote TYPE=CITE>Hi Christian
<p>I don't know if this was pointed out already.
<br>I am looking at H248_Implementors_guide_approved.zip.
<p>The change for Section 6.3&nbsp; Cold Start has the following:
<br>"If the MGC accepts the MG, it will send a Transaction Reply, with
the ServiceChangeMgcId
<br>set to itself."
<p>The change for Section 11.2 Cold Start has the following:
<br>"If the MGC accepts the MG's resignation, it sends a Transaction Reply
<b>not
</b>including
a
<br>ServiceChangeMgcId parameter."
<p>This 2 statements contradict each other.
<br>I think originally it was always "not" including a ServiceChangeMgcId
parameter.
<p>Also additional words might be added to clearly stated that
<br>"If the MG receives a Transaction Reply that includes a ServiceChangeMgcId
parameter, it sends
<br>a ServiceChange <b>w/a method of Restart </b>to the MGC specified in
the ServiceChangeMgcId."
<p>Otherwise someone might get confused and use ServiceChange w/a method
of handoff.
<p>Chuong</blockquote>
</blockquote>
</blockquote>

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

</body>
</html>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Dec 12 15:41:30 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07305
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 12 Dec 2000 15:41:29 -0500 (EST)
Received: from standards (47.234.32.16:2671) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC20F7@standards.nortelnetworks.com>; Tue, 12 Dec 2000 15:21:48 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9134 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 12 Dec 2000 15:21:48 -0500
Received: from alemail1.firewall.lucent.com (alemail1.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC20F6@standards.nortelnetworks.com>; Tue, 12 Dec 2000
          15:21:48 -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 PAA23700
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 12 Dec 2000 15:39:46
          -0500 (EST)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by
          alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id PAA23686
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 12 Dec 2000 15:39:45
          -0500 (EST)
Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id PAA02828; Tue, 12 Dec
          2000 15:39:44 -0500
Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id
          PAA02825; Tue, 12 Dec 2000 15:39:43 -0500
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3A368CBC.B2C59262@lucent.com>
Date:         Tue, 12 Dec 2000 15:38:20 -0500
Reply-To: Troy Cauble <troy@bell-labs.com>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Troy Cauble <troy@LUCENT.COM>
Subject:      MEGACO: Statistics Parameter Value
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Section 6.25 of the Implementor's Guide says

        statisticsParameter = pkgdName EQUAL VALUE

should be changed to

        statisticsParameter = pkgdName [ EQUAL VALUE ]


If so, the corresponding ASN.1 'statValue' should be
OPTIONAL.

-troy


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Dec 12 22:15:10 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA20287
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 12 Dec 2000 22:15:09 -0500 (EST)
Received: from standards (47.234.32.16:2362) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2254@standards.nortelnetworks.com>; Tue, 12 Dec 2000 21:55:38 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9602 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 12 Dec 2000 21:55:38 -0500
Received: from extmx.itri.org.tw by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBC2253@standards.nortelnetworks.com>; Tue, 12 Dec 2000 21:55:03
          -0500
Received: from mail3.itri.org.tw (mail3.itri.org.tw [140.96.157.3]) by
          extmx.itri.org.tw (8.8.8/8.8.8) with ESMTP id LAA12430 for
          <MEGACO@STANDARDS.NORTELNETWORKS.com>; Wed, 13 Dec 2000 11:04:31
          +0800 (CST)
Received: from nti.itri.org.tw (nti.itri.org.tw [140.96.157.2]) by
          mail3.itri.org.tw (8.9.3+Sun/8.9.1) with ESMTP id LAA28900 for
          <MEGACO@STANDARDS.NORTELNETWORKS.com>; Wed, 13 Dec 2000 11:05:24
          +0800 (CST)
Received: from cclmail.ccl.itri.org.tw (cclmail.ccl.itri.org.tw
          [140.96.90.193]) by nti.itri.org.tw (8.8.8/8.8.8) with ESMTP id
          LAA21234 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 13 Dec 2000
          11:01:31 +0800 (CST)
Received: from Exsior ([140.96.102.175]) by cclmail.ccl.itri.org.tw (Lotus
          Domino Release 5.0.2a (Intl)) with SMTP id 2000121311020071:4105 ;
          Wed, 13 Dec 2000 11:02:00 +0800
References: <3A2D2732.894B17D3@usa.alcatel.com>
            <3A301413.B386DBB4@americasm01.nt.com>
            <3A30EBA9.A3DCDB98@usa.alcatel.com>
            <3A312D56.E2954351@americasm01.nt.com>
            <3A31447E.F6AC0947@usa.alcatel.com>
            <3A34FD01.C74499CA@americasm01.nt.com>
            <3A363880.3462E9D9@usa.alcatel.com>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-MIMETrack: Itemize by SMTP Server on CCLMAIL/ITRI(Release 5.0.2a (Intl)|23
             November 1999) at 2000/12/13 11:02:00 AM,
             Serialize by Router on CCLMAIL/ITRI(Release 5.0.2a (Intl)|23
             November 1999) at 2000/12/13 11:02:12 AM,
             Serialize complete at 2000/12/13 11:02:12 AM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="big5"
Message-ID:  <00bf01c064b1$5528cc60$af66608c@Exsior>
Date:         Wed, 13 Dec 2000 11:03:56 +0800
Reply-To: =?big5?B?ufmr27n8?= <yjliao@itri.org.tw>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: =?big5?B?ufmr27n8?= <yjliao@itri.org.tw>
Subject:      Binary encoding in SDP
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi Sir :

We have a question about binary encoding in SDP, can you help us?
In Annex A, SDP binary encoding use :
ProperParm :: = SEQUENCE
{
    name    pKgdName,
    value    SEQUENCE OF OCTET STRING,
    ....
}

if I want to encode the following SDP:
v=0
c=IN IP4 $

1. What I need to put in PropertyParm.name ?
v=0                =====> 0000B001
c=IN IP4 $     =====>  0000B008 or 00006001

2. What I need to put in PropertyParm.value?
Is ASCII of all the string "v=0" and "c=IN IP4 $" or someing else ?

Best regards
Yieng-Chang Liao


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec 13 04:26:42 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA04687
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 13 Dec 2000 04:26:41 -0500 (EST)
Received: from standards (47.234.32.16:2813) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2318@standards.nortelnetworks.com>; Wed, 13 Dec 2000 4:06:59 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 9860 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Dec 2000 04:06:59 -0500
Received: from hindon.hss.co.in (202.54.26.202:55542) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC2317@standards.nortelnetworks.com>; Wed, 13 Dec 2000
          3:56:55 -0500
Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in
          (8.10.0/8.10.0) with SMTP id eBD9GEX01607 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 13 Dec 2000 14:46:15
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          652569B4.0031B70B ; Wed, 13 Dec 2000 14:33:01 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <652569B4.0031B5E4.00@sandesh.hss.hns.com>
Date:         Wed, 13 Dec 2000 14:44:39 +0530
Reply-To: vibansal@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Vivek Bansal <vibansal@HSS.HNS.COM>
Subject:      Clearification in Megaco mib draft 01
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi

Some clearification regarding draft 01 of megaco mib is needed.

mediaGatewayNumTimerRecovery OBJECT-TYPE
    SYNTAX         Counter32
    ACCESS         read-only
    STATUS         mandatory
    DESCRIPTION    "Number of timer recovery events since the
              statistics was last reset. This reflects
              all timers."
    ::= { mediaGatewayTableEntry 11 }

What does the timer recovery event here refers to:

recovery action when protocol timers like stop timer or start timer fails
or
recovery action when the protocol timer expires, like generation of pending in
case provisional rsponse timer expires
or retransmission in case retransmission timer expires.

Kindly clearify.

regards
Vivek Bansal


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec 13 11:06:59 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07410
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 13 Dec 2000 11:06:59 -0500 (EST)
Received: from standards (47.234.32.16:3118) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2458@standards.nortelnetworks.com>; Wed, 13 Dec 2000 10:47:38 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 10305 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Dec 2000 10:47:37 -0500
Received: from radvpost.us.radvision.com (38.150.216.6:41273) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC2457@standards.nortelnetworks.com>; Wed, 13 Dec 2000
          10:47:37 -0500
Received: by RADVPOST with Internet Mail Service (5.5.2650.21) id <YZWLV5P2>;
          Wed, 13 Dec 2000 11:05:13 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <0D5BBF5D638DD4119E3400508BD9494524F863@RADVPOST>
Date:         Wed, 13 Dec 2000 11:05:13 -0500
Reply-To: Dan Elbert <DElbert@RADVISION.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Dan Elbert <DElbert@RADVISION.COM>
Subject:      Context Delete
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

In the spec it is specified that a context is deleted  "If the last
remaining Termination is moved out of a Context" .
But there is no similar statement for the Subtract command.
Should we assume also that the context is deleted if the last termination is
substracted from it ?
And what should happen if in the same action there is first a Subtract and
them an Add for the context ?

Thanks,

Dan Elbert


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec 13 12:03:58 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14161
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 13 Dec 2000 12:03:57 -0500 (EST)
Received: from standards (47.234.32.16:3118) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2527@standards.nortelnetworks.com>; Wed, 13 Dec 2000 11:44:21 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 10585 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Dec 2000 11:44:20 -0500
Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC2526@standards.nortelnetworks.com>; Wed, 13 Dec 2000
          11:44:20 -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 MAA23725
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 13 Dec 2000 12:02:20
          -0500 (EST)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by
          hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id MAA23714
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 13 Dec 2000 12:02:20
          -0500 (EST)
Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id MAA12953; Wed, 13 Dec
          2000 12:02:18 -0500
Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id
          MAA12949; Wed, 13 Dec 2000 12:02:17 -0500
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3A37AB48.9AD47355@lucent.com>
Date:         Wed, 13 Dec 2000 12:00:56 -0500
Reply-To: Troy Cauble <troy@bell-labs.com>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Troy Cauble <troy@LUCENT.COM>
Subject:      MEGACO: Value ::= SEQUENCE OF OCTET STRING
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Section 6.44 of the Implementors Guide changed
the specification of the ASN.1 "Value", to fix
a problem with EventParameter/value (and presumably
SigParameter/value).

        Value ::= SEQUENCE OF OCTET STRING
                  ^^^^^^^^^^^

This change also affects StatisticsParameter/value,
and ServiceChangeParm/serviceChangeReason.
Do these items need a *SEQUENCE OF* OCTET STRING ?

-troy


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec 13 14:07:16 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04445
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 13 Dec 2000 14:07:14 -0500 (EST)
Received: from standards (47.234.32.16:4593) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC26B2@standards.nortelnetworks.com>; Wed, 13 Dec 2000 13:47:25 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11098 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Dec 2000 13:47:25 -0500
Received: from radvpost.us.radvision.com (38.150.216.6:45806) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC26A5@standards.nortelnetworks.com>; Wed, 13 Dec 2000
          13:37:24 -0500
Received: by RADVPOST with Internet Mail Service (5.5.2650.21) id <YZWLV54Y>;
          Wed, 13 Dec 2000 13:55:01 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C06536.31865360"
Message-ID:  <0D5BBF5D638DD4119E3400508BD949452632CB@RADVPOST>
Date:         Wed, 13 Dec 2000 13:54:59 -0500
Reply-To: Lisa Amberger <lisa@RADVISION.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Lisa Amberger <lisa@RADVISION.COM>
Subject:      Virtual MG's and mId's
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_01C06536.31865360
Content-Type: text/plain;
        charset="iso-8859-1"

We have the following questions concerning MGs and mIds:

1)       Does each virtual MG, potentially located on the same physical MG,
have its own unique mId?
2)       What is a "network interface" as referred to on page 70 of RFC
3015? Is it simply an IP address or
IP and port together?
3)       Can a single mId simultaneously support both a UDP connection and a
TCP connection?

Lisa Amberger

------_=_NextPart_001_01C06536.31865360
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 9">
<meta name=3DOriginator content=3D"Microsoft Word 9">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C0650C.42D1EA00">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {mso-style-parent:"";
        margin:0in;
        margin-bottom:.0001pt;
        mso-pagination:widow-orphan;
        font-size:12.0pt;
        font-family:"Times New Roman";
        mso-fareast-font-family:"Times New Roman";}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
        {margin:0in;
        margin-bottom:.0001pt;
        mso-pagination:widow-orphan;
        font-size:12.0pt;
        font-family:"Times New Roman";
        mso-fareast-font-family:"Times New Roman";}
span.EmailStyle16
        {mso-style-type:personal;
        mso-ansi-font-size:10.0pt;
        mso-ascii-font-family:Arial;
        mso-hansi-font-family:Arial;
        mso-bidi-font-family:Arial;
        color:navy;}
span.EmailStyle17
        {mso-style-type:personal;
        mso-ansi-font-size:10.0pt;
        mso-ascii-font-family:Arial;
        mso-hansi-font-family:Arial;
        mso-bidi-font-family:Arial;
        color:#993366;}
span.EmailStyle18
        {mso-style-type:personal;
        mso-ansi-font-size:10.0pt;
        mso-ascii-font-family:Arial;
        mso-hansi-font-family:Arial;
        mso-bidi-font-family:Arial;
        color:#003300;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        mso-ansi-font-size:10.0pt;
        mso-ascii-font-family:Arial;
        mso-hansi-font-family:Arial;
        mso-bidi-font-family:Arial;
        color:olive;}
@page Section1
        {size:8.5in 11.0in;
        margin:1.0in 1.25in 1.0in 1.25in;
        mso-header-margin:.5in;
        mso-footer-margin:.5in;
        mso-paper-source:0;}
div.Section1
        {page:Section1;}
 /* List Definitions */
@list l0
        {mso-list-id:721976706;
        mso-list-type:hybrid;
        mso-list-template-ids:206852040 67698705 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
        {mso-level-text:"%1\)";
        mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1027"/>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1"/>
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=3Dwhite lang=3DEN-US style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt;color:black'>We have the following questions =
concerning
MGs and mIds:</span></font><font color=3Dblack><span =
style=3D'color:black;
mso-color-alt:windowtext'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><span class=3DEmailStyle17><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial;color:black'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font></span><span
class=3DEmailStyle17><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;color:black;mso-color=
-alt:
windowtext'><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo2;
tab-stops:list .5in'><![if !supportLists]><span =
class=3DEmailStyle17><font
size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial;color:black;mso-color-alt:windowtext'>1)<font =
size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></font></span><![endif]><span =
class=3DEmailStyle17><font
size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial;color:black'>Does each virtual MG, potentially =
located
on the same physical MG, have its own unique =
mId?</span></font></span><span
class=3DEmailStyle17><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;color:black;mso-color=
-alt:
windowtext'><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo2;
tab-stops:list .5in'><![if !supportLists]><span =
class=3DEmailStyle17><font
size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial;color:black;mso-color-alt:windowtext'>2)<font =
size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></font></span><![endif]><span =
class=3DEmailStyle17><font
size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial;color:black'>What is a &#8220;network =
interface&#8221; as referred
to on page 70 of RFC 3015?</span></font></span><span =
class=3DEmailStyle17><font
size=3D2 color=3D"#003300" face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial;color:#003300'> Is it simply an IP address =
or</span></font></span><span
class=3DEmailStyle17><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;color:black;mso-color=
-alt:
windowtext'><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal style=3D'margin-left:.5in'><span =
class=3DEmailStyle18><font
size=3D2 color=3D"#003300" face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial'>IP and port =
together?</span></font></span><span
class=3DEmailStyle18><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;color:black;mso-color=
-alt:
windowtext'><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal =
style=3D'margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo2;
tab-stops:list .5in'><![if !supportLists]><span =
class=3DEmailStyle17><font
size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial;color:black;mso-color-alt:windowtext'>3)<font =
size=3D1
face=3D"Times New Roman"><span style=3D'font:7.0pt "Times New =
Roman"'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></font></span><![endif]><span =
class=3DEmailStyle17><font
size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial;color:black'>Can a single mId simultaneously =
support
both a UDP connection and a TCP connection?</span></font></span><span
class=3DEmailStyle17><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;color:black;mso-color=
-alt:
windowtext'><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle17><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial;color:black'><![if =
!supportEmptyParas]>&nbsp;<![endif]></span></font></span><span
class=3DEmailStyle17><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:
10.0pt;mso-bidi-font-size:12.0pt;font-family:Arial;color:black;mso-color=
-alt:
windowtext'><o:p></o:p></span></font></span></p>

<p class=3DMsoNormal><span class=3DEmailStyle17><font size=3D2 =
color=3Dblack
face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:12.0pt;font-family:
Arial;color:black'>Lisa Amberger</span></font></span><span =
class=3DEmailStyle17><font
size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;mso-bidi-font-size:
12.0pt;font-family:Arial;color:black;mso-color-alt:windowtext'><o:p></o:=
p></span></font></span></p>

</div>

</body>

</html>

------_=_NextPart_001_01C06536.31865360--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec 13 15:07:28 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12502
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 13 Dec 2000 15:07:27 -0500 (EST)
Received: from standards (47.234.32.16:3129) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC26F0@standards.nortelnetworks.com>; Wed, 13 Dec 2000 14:46:28 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11185 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Dec 2000 14:46:28 -0500
Received: from fire.integralaccess.com (63.160.25.239:3885) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC26E7@standards.nortelnetworks.com>; Wed, 13 Dec 2000
          14:36:28 -0500
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: <IMail v6.04>
Message-ID:  <200012131501.AA71762606@fire.integralaccess.com>
Date:         Wed, 13 Dec 2000 15:01:21 -0500
Reply-To: mtam@fire.integralaccess.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Mimi Tam <mtam@FIRE.INTEGRALACCESS.COM>
Subject:      Re: What dose BOF(birds of a feather) mean?
X-To:         Michael Thomas <mat@CISCO.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Or agree to disagree...Mimi :)


---------- Original Message ----------------------------------
From:         Michael Thomas <mat@CISCO.COM>
Reply-To:     Michael Thomas <mat@CISCO.COM>
Date:         Mon, 11 Dec 2000 19:00:05 -0800

>Lien, Yan Tsung writes:
> > What dose BOF(birds of a feather) mean?
>
>   Ah, cultural imperialism at its best :-)
>
>   There is an old quip that "birds of a feather
>   flock together". Meaning birds of the same species
>   stay in flocks together. BOF is a contraction
>   of that, and roughly means "people interested in
>   a class of problem that they think should be
>   solved". In IETF context, it's a process to get
>   the IESG to agree :-)
>
>            Mike
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec 13 17:36:24 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03823
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 13 Dec 2000 17:36:24 -0500 (EST)
Received: from standards (47.234.32.16:2695) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC27DC@standards.nortelnetworks.com>; Wed, 13 Dec 2000 17:16:47 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11500 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Dec 2000 17:16:47 -0500
Received: from topaz.3com.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBC27C6@standards.nortelnetworks.com>; Wed, 13 Dec 2000 17:06:47
          -0500
Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com
          (Switch-2.0.1/Switch-2.0.1) with ESMTP id eBDMNo024691 for
          <megaco@standards.nortelnetworks.com>; Wed, 13 Dec 2000 14:23:54
          -0800 (PST)
Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM
          [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with
          SMTP id eBDMOh306918 for <megaco@standards.nortelnetworks.com>; Wed,
          13 Dec 2000 14:24:43 -0800 (PST)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))
          id 882569B4.007B41EF ; Wed, 13 Dec 2000 14:26:18 -0800
X-Lotus-FromDomain: 3COM
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <882569B4.007B3E52.00@hqoutbound.ops.3com.com>
Date:         Wed, 13 Dec 2000 16:25:23 -0600
Reply-To: Natarajan_Kalpathy@3COM.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Natarajan Kalpathy <Natarajan_Kalpathy@3COM.COM>
Subject:      Question on Keep Alives
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This question is regarding the keep alives between MGC and MG.

why dont we use Service change Command for Keep alive mechanism . We can extend
the Service change method to include
Keep Alive Method. The advantage being :-

1) The polling mechanism can either be at MGC or MG . (i-e it can be provisioned
to exist either at MGC or MG)
2) If we Use Notify then there are 4 Msgs going back and forth between MGC and
MG for each keep alive interval.

MODIFY(Event descriptor = KEEP ALIVE);
MODIFTRSP();

NOTIFY(KEEP ALIVE)
NOTIFYREPLY()

regards,
Natarajan


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec 13 18:42:45 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17242
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 13 Dec 2000 18:42:44 -0500 (EST)
Received: from standards (47.234.32.16:4887) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2833@standards.nortelnetworks.com>; Wed, 13 Dec 2000 18:22:36 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11610 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Dec 2000 18:22:36 -0500
Received: from zrchh190 (47.158.65.22:42991) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC281B@standards.nortelnetworks.com>; Wed, 13 Dec 2000 18:12:36
          -0500
Received: from smtprch1.nortel.com (actually erchg0j) by zrchh190; Wed, 13 Dec
          2000 17:31:42 -0600
Received: from zcard015.ca.nortel.com (actually zcard015) by
          smtprch1.nortel.com; Wed, 13 Dec 2000 17:30:17 -0600
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id
          <YMX1B4RV>; Wed, 13 Dec 2000 18:30:10 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
X-Orig: <taylor@nortelnetworks.com>
Message-ID:  <28560036253BD41191A10000F8BCBD1103242C88@zcard00g.ca.nortel.com>
Date:         Wed, 13 Dec 2000 18:30:07 -0500
Reply-To: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Subject:      Re: [Fwd: unsubscribe megaco daniel madden]
X-To:         Daniel Madden <Daniel.Madden@tellabs.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Sorry, I'll do it right now....done.  Must be a matter of syntax, since your
address hasn't changed.  I'm pretty sure "signoff megaco" in the body would
work.

> -----Original Message-----
> From: Daniel Madden [mailto:Daniel.Madden@tellabs.com]
> Sent: Wednesday, December 13, 2000 3:09 PM
> To: listserv@standards.nortelnetworks.com; ietf-web@ietf.org; Taylor,
> Tom-PT [NORSE:B901:EXCH]
> Subject: Re: [Fwd: unsubscribe megaco daniel madden]
>
>
> Hi all,
>
> Still not able to unsubscribe from this mailing list -- have tried the
> following a million times (and variants thereof) over the
> last 2 weeks:
>
> To: listserv@standards.nortelnetworks.com
> Subject:
> Body: unsubscribe megaco
>
> Any suggestions/help please in unsubscribing
>
> Thanks,
> Daniel Madden
>
>
>
> Daniel Madden wrote:
>
> > Hi ,
> >
> >  I have retried unsubscribing from the mailing list  numerous times
> > without any sucess for the past week.
> > Any help would be appreciated.
> >
> > Thanks,
> > Daniel Madden
> >
> > > Hello,
> > >
> > > Unfortunalely I have failed to unsubsribe from the megaco
> mailing list
> > > following a number of attempts. As per the instructions,
> a mail is sent
> > > to listserv@standards.nortelnetworks.com with
> unsubscribe megaco first
> > > name last name (i.e. unsubscribe megaco daniel madden) in
> the subject
> > > box and body. However this fails. I have also tried
> without sucess, the
> > > other options of enclosing unsubscribe megaco daniel
> madden in just the
> > > subject area or in just the body area. ietf-web@ietf.org.
> > >
> > > Any suggestions or remedies would be kindly appreciated.
> > >
> > > Thanks very much,
> > > Daniel Madden
> > >
> > > Daniel Madden wrote:
> > >
> > > > unsubscribe megaco daniel madden
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec 13 18:52:03 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19224
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 13 Dec 2000 18:52:03 -0500 (EST)
Received: from standards (47.234.32.16:4887) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC285B@standards.nortelnetworks.com>; Wed, 13 Dec 2000 18:31:54 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11692 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Dec 2000 18:31:54 -0500
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC285A@standards.nortelnetworks.com>; Wed, 13 Dec 2000 18:31:43
          -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id SAA23950; Wed, 13 Dec 2000 18:46:55 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com
          (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by
          mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id SAA20156;
          Wed, 13 Dec 2000 18:46:58 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <Y6AVCXJA>; Wed, 13 Dec 2000 18:46:56 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF01A6EB98@whq-msgusr-02.pit.comms.marconi.com>
Date:         Wed, 13 Dec 2000 18:46:53 -0500
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: Question on Keep Alives
X-To:         "Natarajan_Kalpathy@3COM.COM" <Natarajan_Kalpathy@3COM.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

There is no need to do this.
The MGC can do an Audit if it doesn't see any traffic from the MGC for
a while

The MG can do a noop ServiceChange if it doesn't see any traffic from
the MG for a while.

Since there is an acceptable mechanism now, we should not add another.

Brian

> -----Original Message-----
> From: Natarajan Kalpathy [mailto:Natarajan_Kalpathy@3COM.COM]
> Sent: Wednesday, December 13, 2000 5:25 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Question on Keep Alives
>
>
> This question is regarding the keep alives between MGC and MG.
>
> why dont we use Service change Command for Keep alive
> mechanism . We can extend
> the Service change method to include
> Keep Alive Method. The advantage being :-
>
> 1) The polling mechanism can either be at MGC or MG . (i-e it
> can be provisioned
> to exist either at MGC or MG)
> 2) If we Use Notify then there are 4 Msgs going back and
> forth between MGC and
> MG for each keep alive interval.
>
> MODIFY(Event descriptor = KEEP ALIVE);
> MODIFTRSP();
>
> NOTIFY(KEEP ALIVE)
> NOTIFYREPLY()
>
> regards,
> Natarajan
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec 13 19:06:33 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22779
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 13 Dec 2000 19:06:32 -0500 (EST)
Received: from standards (47.234.32.16:4887) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2872@standards.nortelnetworks.com>; Wed, 13 Dec 2000 18:46:31 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11719 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Dec 2000 18:46:31 -0500
Received: from mail.winsocket.com (sdsl-216-46-65-3.dsl.nyc.megapath.net) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC286F@standards.nortelnetworks.com>; Wed, 13 Dec 2000
          18:36:31 -0500
Received: from localhost.localdomain [24.162.65.91] by mail.winsocket.com
          (SMTPD32-6.04) id AC37206013C; Wed, 13 Dec 2000 18:54:31 -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.50.4522.1200
Message-ID:  <NEBBIELHMLDIACLLJHCNMEHOCHAA.plong@packetizer.com>
Date:         Wed, 13 Dec 2000 17:54:32 -0600
Reply-To: plong@ipdialog.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Paul Long <plong@PACKETIZER.COM>
Subject:      context-free?
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <882569B4.007B3E52.00@hqoutbound.ops.3com.com>
Content-Transfer-Encoding: 7bit

Does the text encoding use a context-free grammar? This cannot be discerned
from the ABNF. For example, does "A" always represent the AddToken and never
a name, e.g., a digitMapName?

Paul Long
ipDialog, Inc.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec 13 19:21:32 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26229
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 13 Dec 2000 19:21:31 -0500 (EST)
Received: from standards (47.234.32.16:4887) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC288F@standards.nortelnetworks.com>; Wed, 13 Dec 2000 19:01:41 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11757 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Dec 2000 19:01:41 -0500
Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC288E@standards.nortelnetworks.com>; Wed, 13 Dec 2000
          19:01:40 -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 TAA27906
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 13 Dec 2000 19:19:32
          -0500 (EST)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by
          hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id TAA27900
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 13 Dec 2000 19:19:31
          -0500 (EST)
Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id TAA17067; Wed, 13 Dec
          2000 19:19:30 -0500
Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id
          TAA17060; Wed, 13 Dec 2000 19:19:29 -0500
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Original-CC: MEGACO@STANDARDS.NORTELNETWORKS.COM
References: <NEBBIELHMLDIACLLJHCNMEHOCHAA.plong@packetizer.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3A3811BE.219F22BA@lucent.com>
Date:         Wed, 13 Dec 2000 19:18:06 -0500
Reply-To: Troy Cauble <troy@bell-labs.com>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Troy Cauble <troy@LUCENT.COM>
Subject:      Re: context-free?
X-To:         plong@ipdialog.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Paul Long wrote:
>
> Does the text encoding use a context-free grammar? This cannot be discerned
> from the ABNF. For example, does "A" always represent the AddToken and never
> a name, e.g., a digitMapName?
>
> Paul Long
> ipDialog, Inc.

No.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec 13 20:57:18 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18964
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 13 Dec 2000 20:57:17 -0500 (EST)
Received: from standards (47.234.32.16:2549) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC28FF@standards.nortelnetworks.com>; Wed, 13 Dec 2000 20:37:40 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 11906 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 13 Dec 2000 20:37:40 -0500
Received: from thalia.fm.intel.com (132.233.247.11:3851) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC28FE@standards.nortelnetworks.com>; Wed, 13 Dec 2000
          20:37:39 -0500
Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by
          thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21
          19:27:27 smothers Exp $) with SMTP id BAA22525; Thu, 14 Dec 2000
          01:56:57 GMT
Received: from fmsmsx27.FM.INTEL.COM ([132.233.48.27]) by 132.233.48.204
          (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 14 Dec 2000
          01:55:37 0000 (GMT)
Received: by fmsmsx27.fm.intel.com with Internet Mail Service (5.5.2650.21) id
          <YYVHBLGB>; Wed, 13 Dec 2000 17:55:35 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C06570.5CA5DBD0"
Message-ID:  <F1CE15E08172D4119247009027AE9D50029E3620@FMSMSX37>
Date:         Wed, 13 Dec 2000 17:51:23 -0800
Reply-To: "Kaul, Bharat" <bharat@TRILLIUM.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Kaul, Bharat" <bharat@TRILLIUM.COM>
Subject:      Re: Virtual MG's and mId's
X-To:         Lisa Amberger <lisa@RADVISION.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_01C06570.5CA5DBD0
Content-Type: text/plain;
        charset="ISO-8859-1"

Please see my comments below.
-----Original Message-----
From: Lisa Amberger [mailto:lisa@RADVISION.COM]
Sent: Wednesday, December 13, 2000 10:55 AM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Virtual MG's and mId's


We have the following questions concerning MGs and mIds:

1)       Does each virtual MG, potentially located on the same physical MG,
have its own unique mId?

[Bharat Kaul]

Each virtual MG has a unique MID which remains consistent in all messages.
This is true for the lifetime of the control association with the MGC

2)       What is a "network interface" as referred to on page 70 of RFC
3015? Is it simply an IP address or
IP and port together?

[Bharat Kaul]
The reference is to IP address there.

3)       Can a single mId simultaneously support both a UDP connection and a
TCP connection?

[Bharat Kaul]

The answer is yes as an MGC is required to support both transports. An MG
uses only one transport at one point of time and hence for MG, its MID can
use only one transport.


- Bharat

------_=_NextPart_001_01C06570.5CA5DBD0
Content-Type: text/html;
        charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:v =
"urn:schemas-microsoft-com:vml" xmlns:o =
"urn:schemas-microsoft-com:office:office" xmlns:w =
"urn:schemas-microsoft-com:office:word"><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">


<META content=Word.Document name=ProgId>
<META content="MSHTML 5.00.2314.1000" name=GENERATOR>
<META content="Microsoft Word 9" name=Originator><LINK
href="cid:filelist.xml@01C0650C.42D1EA00" rel=File-List><!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:Zoom>0</w:Zoom>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
 </w:WordDocument>
</xml><![endif]-->
<STYLE>
<!--
 /* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {mso-style-parent:"";
        margin:0in;
        margin-bottom:.0001pt;
        mso-pagination:widow-orphan;
        font-size:12.0pt;
        font-family:"Times New Roman";
        mso-fareast-font-family:"Times New Roman";}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
        {margin:0in;
        margin-bottom:.0001pt;
        mso-pagination:widow-orphan;
        font-size:12.0pt;
        font-family:"Times New Roman";
        mso-fareast-font-family:"Times New Roman";}
span.EmailStyle16
        {mso-style-type:personal;
        mso-ansi-font-size:10.0pt;
        mso-ascii-font-family:Arial;
        mso-hansi-font-family:Arial;
        mso-bidi-font-family:Arial;
        color:navy;}
span.EmailStyle17
        {mso-style-type:personal;
        mso-ansi-font-size:10.0pt;
        mso-ascii-font-family:Arial;
        mso-hansi-font-family:Arial;
        mso-bidi-font-family:Arial;
        color:#993366;}
span.EmailStyle18
        {mso-style-type:personal;
        mso-ansi-font-size:10.0pt;
        mso-ascii-font-family:Arial;
        mso-hansi-font-family:Arial;
        mso-bidi-font-family:Arial;
        color:#003300;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        mso-ansi-font-size:10.0pt;
        mso-ascii-font-family:Arial;
        mso-hansi-font-family:Arial;
        mso-bidi-font-family:Arial;
        color:olive;}
@page Section1
        {size:8.5in 11.0in;
        margin:1.0in 1.25in 1.0in 1.25in;
        mso-header-margin:.5in;
        mso-footer-margin:.5in;
        mso-paper-source:0;}
div.Section1
        {page:Section1;}
 /* List Definitions */
@list l0
        {mso-list-id:721976706;
        mso-list-type:hybrid;
        mso-list-template-ids:206852040 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
        {mso-level-text:"%1\)";
        mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
-->
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1027"/>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1"/>
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY bgColor=white lang=EN-US style="tab-interval: .5in">
<DIV><FONT color=#ff0000 face=Arial size=2><SPAN class=809275101-14122000>Please
see my comments below.</SPAN></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma
  size=2>-----Original Message-----<BR><B>From:</B> Lisa Amberger
  [mailto:lisa@RADVISION.COM]<BR><B>Sent:</B> Wednesday, December 13, 2000 10:55
  AM<BR><B>To:</B> MEGACO@STANDARDS.NORTELNETWORKS.COM<BR><B>Subject:</B>
  Virtual MG's and mId's<BR><BR></DIV></FONT>
  <DIV class=Section1>
  <P class=MsoNormal><FONT color=black face="Times New Roman" size=3><SPAN
  style="COLOR: black; FONT-SIZE: 12pt">We have the following questions
  concerning MGs and mIds:</SPAN></FONT><FONT color=black><SPAN
  style="COLOR: black; mso-color-alt: windowtext"><o:p></o:p></SPAN></FONT></P>
  <P class=MsoNormal><SPAN class=EmailStyle17><FONT color=black face=Arial
  size=2><SPAN
  style="COLOR: black; FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt"><![if !supportEmptyParas]>&nbsp;<![endif]></SPAN></FONT></SPAN><SPAN
  class=EmailStyle17><FONT color=black face=Arial size=2><SPAN
  style="COLOR: black; FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-color-alt: windowtext; mso-bidi-font-size: 12.0pt"><o:p></o:p></SPAN></FONT></SPAN></P><![if !supportLists]>
  <P class=MsoNormal
  style="MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo2; tab-stops: list .5in"><SPAN
  class=EmailStyle17><FONT color=black><SPAN
  style="COLOR: black; FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-color-alt: windowtext; mso-bidi-font-size: 12.0pt">1)<FONT
  face=Arial size=2><SPAN
  style="FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  </SPAN></FONT></SPAN></FONT></SPAN><![endif]><SPAN class=EmailStyle17><FONT
  color=black><SPAN
  style="COLOR: black; FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt">Does
  each virtual MG, potentially located on the same physical MG, have its own
  unique mId?<BR><FONT color=#ff0000><SPAN
  class=809275101-14122000></SPAN></FONT></SPAN></FONT></SPAN></P>
  <P class=MsoNormal
  style="MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo2; tab-stops: list .5in"><SPAN
  class=EmailStyle17><FONT color=black><SPAN
  style="COLOR: black; FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt"><FONT
  color=#ff0000><SPAN class=809275101-14122000>[Bharat
  Kaul]&nbsp;</SPAN></FONT></SPAN></FONT></SPAN></P>
  <P class=MsoNormal
  style="MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo2; tab-stops: list .5in"><SPAN
  class=EmailStyle17><FONT color=black><SPAN
  style="COLOR: black; FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt"><FONT
  color=#ff0000><SPAN
  class=809275101-14122000></SPAN></FONT></SPAN></FONT></SPAN>&nbsp;</P>
  <P class=MsoNormal
  style="MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo2; tab-stops: list .5in"><SPAN
  class=EmailStyle17><FONT color=black><SPAN
  style="COLOR: black; FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt"><FONT
  color=#ff0000><SPAN class=809275101-14122000>Each virtual MG has a unique MID
  which remains consistent in all messages. This is true for the lifetime of the
  control association with the MGC</SPAN></FONT></SPAN></FONT></SPAN></P>
  <P class=MsoNormal
  style="MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo2; tab-stops: list .5in"><SPAN
  class=EmailStyle17><FONT color=black><SPAN
  style="COLOR: black; FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt"><FONT
  color=#ff0000><SPAN
  class=809275101-14122000>&nbsp;</SPAN></FONT></SPAN></FONT></SPAN><SPAN
  class=EmailStyle17><FONT color=black><SPAN
  style="COLOR: black; FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-color-alt: windowtext; mso-bidi-font-size: 12.0pt"><o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=MsoNormal
  style="MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo2; tab-stops: list .5in"><![if !supportLists]><SPAN
  class=EmailStyle17><FONT color=black face=Arial size=2><SPAN
  style="COLOR: black; FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-color-alt: windowtext; mso-bidi-font-size: 12.0pt">2)<FONT
  face="Times New Roman" size=1><SPAN
  style="FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  </SPAN></FONT></SPAN></FONT></SPAN><![endif]><SPAN class=EmailStyle17><FONT
  color=black face=Arial size=2><SPAN
  style="COLOR: black; FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt">What
  is a &#8220;network interface&#8221; as referred to on page 70 of RFC
  3015?</SPAN></FONT></SPAN><SPAN class=EmailStyle17><FONT color=#003300
  face=Arial size=2><SPAN
  style="COLOR: #003300; FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt">
  Is it simply an IP address or</SPAN></FONT></SPAN><SPAN
  class=EmailStyle17><FONT color=black face=Arial size=2><SPAN
  style="COLOR: black; FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-color-alt: windowtext; mso-bidi-font-size: 12.0pt"><o:p></o:p></SPAN></FONT></SPAN></P>
  <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><SPAN class=EmailStyle18><FONT
  color=#003300><SPAN
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt">IP and
  port together?<BR><FONT color=#ff0000><SPAN
  class=809275101-14122000></SPAN></FONT></SPAN></FONT></SPAN></P>
  <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><SPAN class=EmailStyle18><FONT
  color=#003300><SPAN
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt"><FONT
  color=#ff0000><SPAN class=809275101-14122000>[Bharat
  Kaul]&nbsp;</SPAN></FONT></SPAN></FONT></SPAN></P>
  <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><SPAN class=EmailStyle18><FONT
  color=#003300><SPAN
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt"><FONT
  color=#ff0000><SPAN class=809275101-14122000>The reference is to IP address
  there.</SPAN></FONT></SPAN></FONT></SPAN></P>
  <P class=MsoNormal style="MARGIN-LEFT: 0.5in"><SPAN class=EmailStyle18><FONT
  color=#003300><SPAN
  style="FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt"><FONT
  color=#ff0000><SPAN
  class=809275101-14122000>&nbsp;</SPAN></FONT></SPAN></FONT></SPAN><SPAN
  class=EmailStyle18><FONT color=black><SPAN
  style="COLOR: black; FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-color-alt: windowtext; mso-bidi-font-size: 12.0pt"><o:p></o:p></SPAN></FONT></SPAN></P><![if !supportLists]>
  <P class=MsoNormal
  style="MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo2; tab-stops: list .5in"><SPAN
  class=EmailStyle17><FONT color=black><SPAN
  style="COLOR: black; FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-color-alt: windowtext; mso-bidi-font-size: 12.0pt">3)<FONT
  face=Arial size=2><SPAN
  style="FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
  </SPAN></FONT></SPAN></FONT></SPAN><![endif]><SPAN class=EmailStyle17><FONT
  color=black><SPAN
  style="COLOR: black; FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt">Can
  a single mId simultaneously support both a UDP connection and a TCP
  connection?<BR><FONT color=#ff0000><SPAN
  class=809275101-14122000></SPAN></FONT></SPAN></FONT></SPAN></P>
  <P class=MsoNormal
  style="MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo2; tab-stops: list .5in"><SPAN
  class=EmailStyle17><FONT color=black><SPAN
  style="COLOR: black; FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt"><FONT
  color=#ff0000><SPAN class=809275101-14122000>[Bharat
  Kaul]&nbsp;</SPAN></FONT></SPAN></FONT></SPAN></P>
  <P class=MsoNormal
  style="MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo2; tab-stops: list .5in"><SPAN
  class=EmailStyle17><FONT color=black><SPAN
  style="COLOR: black; FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt"><FONT
  color=#ff0000><SPAN
  class=809275101-14122000></SPAN></FONT></SPAN></FONT></SPAN>&nbsp;</P>
  <P class=MsoNormal
  style="MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo2; tab-stops: list .5in"><SPAN
  class=EmailStyle17><FONT color=black><SPAN
  style="COLOR: black; FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt"><FONT
  color=#ff0000><SPAN class=809275101-14122000>The answer is yes as an MGC is
  required to support both transports. An MG uses only one transport at one
  point of time and hence for MG, its MID can use only one
  transport.</SPAN></FONT></SPAN></FONT></SPAN></P><![if !supportEmptyParas]>
  <P class=MsoNormal><SPAN class=EmailStyle17><FONT color=black face=Arial
  size=2><SPAN
  style="COLOR: black; FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt">&nbsp;<![endif]></SPAN></FONT></SPAN></P>
  <P class=MsoNormal><FONT color=#ff0000><SPAN class=EmailStyle17><SPAN
  style="COLOR: black; FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt"><SPAN
  class=809275101-14122000></SPAN></SPAN></SPAN></FONT>&nbsp;</P>
  <P class=MsoNormal><FONT color=#ff0000><SPAN class=EmailStyle17><SPAN
  style="COLOR: black; FONT-FAMILY: Arial; FONT-SIZE: 10pt; mso-bidi-font-size: 12.0pt"><SPAN
  class=809275101-14122000>-
Bharat</SPAN></SPAN></SPAN></FONT></P></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C06570.5CA5DBD0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec 14 00:53:33 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA27848
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 14 Dec 2000 00:53:32 -0500 (EST)
Received: from standards (47.234.32.16:3017) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2999@standards.nortelnetworks.com>; Thu, 14 Dec 2000 0:33:59 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 12102 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 00:33:58 -0500
Received: from mail.packetizer.com (sdsl-216-46-65-3.dsl.nyc.megapath.net) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC2998@standards.nortelnetworks.com>; Thu, 14 Dec 2000
          0:23:58 -0500
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Sender: <plong@mail.packetizer.com>
X-Mailer: <IMail v6.04>
Message-ID:  <200012140042.AA35586368@mail.packetizer.com>
Date:         Thu, 14 Dec 2000 00:42:00 -0500
Reply-To: plong@packetizer.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Paul Long <plong@packetizer.com>
Subject:      Re: context-free?
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Troy,

On what do you base your answer? Is this stated anywhere or is this simply your opinion? Context-dependent grammars are usually more difficult to parse... correctly. :-)

If you are right, I am concerned that those implementations that do not use a simple, most-likely hand-coded, predictive parser but instead use a parser generator where the lexer and parser are separate, e.g., lex/yacc, risk incorrect parsing due to the uncoupling between these two components. The reason is that most programming languages are context-free (C, C++, and Pascal are context-free; PL/I is not) so most implementors presumably have more experience parsing context-free grammars, e.g., programming languages, than context-dependent grammars, such as our Megaco text encoding. Unless implementors take special care to pass the context from the parser back to the lexer, e.g., by having yacc actions shift between lex states, their products will most likely parse

    A = A { M { L { } } }

incorrectly as

    AddToken EQUAL AddToken LBRKT ...
or
    NAME EQUAL NAME LBRKT ...

rather than

    AddToken EQUAL NAME LBRKT ...

This is just a head-up for implementors to make sure that your parser will handle the Megaco ABNF as a context-_dependent_ grammar and to add test cases like the above as a test case to assure correctness.

Paul Long
ipDialog, Inc.

---------- Original Message ----------------------------------
From: Troy Cauble <troy@LUCENT.COM>
Reply-To: Troy Cauble <troy@bell-labs.com>
Date:         Wed, 13 Dec 2000 19:18:06 -0500

>Paul Long wrote:
>>
>> Does the text encoding use a context-free grammar? This cannot be discerned
>> from the ABNF. For example, does "A" always represent the AddToken and never
>> a name, e.g., a digitMapName?
>>
>> Paul Long
>> ipDialog, Inc.
>
>No.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec 14 05:26:11 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA21123
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 14 Dec 2000 05:26:11 -0500 (EST)
Received: from standards (47.234.32.16:1659) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2A08@standards.nortelnetworks.com>; Thu, 14 Dec 2000 5:06:35 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 12255 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 05:06:35 -0500
Received: from albatross-ext.wise.edt.ericsson.se by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC2A03@standards.nortelnetworks.com>; Thu, 14 Dec 2000
          4:56:35 -0500
Received: from esealnt462.al.sw.ericsson.se (esealnt462.al.sw.ericsson.se
          [153.88.251.62]) by albatross.wise.edt.ericsson.se
          (8.11.0/8.11.0/WIREfire-1.3) with SMTP id eBEAEa416012 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 14 Dec 2000 11:14:36
          +0100 (MET)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ;
          Thu Dec 14 11:14:29 2000 +0100
Received: by esealnt743.al.sw.ericsson.se with Internet Mail Service
          (5.5.2651.58) id <X8X1YC4D>; Thu, 14 Dec 2000 11:13:51 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <5E5172B4DE05D311B3AB0008C75DA9410561BBFB@edeacnt100.eed.ericsson.se>
Date:         Thu, 14 Dec 2000 11:14:10 +0100
Reply-To: "Marcello Pantaleo (EED)" <Marcello.Pantaleo@EED.ERICSSON.SE>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Marcello Pantaleo (EED)" <Marcello.Pantaleo@EED.ERICSSON.SE>
Subject:      Re: Context Delete
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Chapter 6.1.2 states: Contexts are deleted implicitly when the last
remaining Termination is subtracted or moved out.

Marcello
-----Original Message-----
From: Dan Elbert [mailto:DElbert@RADVISION.COM]
Sent: Wednesday, December 13, 2000 5:05 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Context Delete


In the spec it is specified that a context is deleted  "If the last
remaining Termination is moved out of a Context" .
But there is no similar statement for the Subtract command.
Should we assume also that the context is deleted if the last termination is
substracted from it ?
And what should happen if in the same action there is first a Subtract and
them an Add for the context ?

Thanks,

Dan Elbert


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec 14 07:46:19 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA14004
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 14 Dec 2000 07:46:18 -0500 (EST)
Received: from standards (47.234.32.16:1567) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2AAC@standards.nortelnetworks.com>; Thu, 14 Dec 2000 7:26:38 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 12483 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 07:26:37 -0500
Received: from mailcity.com (fes-qout.whowhere.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC2AAB@standards.nortelnetworks.com>; Thu, 14 Dec 2000
          7:26:37 -0500
Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Thu Dec 14 04:44:27
          2000
Mime-Version: 1.0
X-Sent-Mail: off
X-Mailer: MailCity Service
X-Sender-Ip: 12.40.232.2
Content-Type: text/plain; charset=us-ascii
Content-Language: en
Content-Transfer-Encoding: 7bit
Message-ID:  <KGHNJFICALPKDAAA@mailcity.com>
Date:         Thu, 14 Dec 2000 04:44:27 -0800
Reply-To: kris_albert@lycos.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Kris Albert <kris_albert@lycos.com>
Organization: Lycos Communications  (http://comm.lycos.com:80)
Subject:      Re: DigMap Related Questions
X-To:         "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

 Hi Tom and List!
I have some new queries after Tom's response. Please see the interspersed queries as Kris>.

thanks,
Kris
--

On Fri, 8 Dec 2000 12:07:04
 Taylor, Tom-PT [NORSE:B901:EXCH] wrote:
>Hi.
>
>> -----Original Message-----
>> From: Kris Albert [mailto:kris_albert@LYCOS.COM]
>> Sent: Wednesday, December 06, 2000 12:17 AM
>> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
>> Subject: [MEGACO] DigMap Related Questions
>>
>>
>> Hi all,
>>       I have few questions related to the digitmaps
>>
>>  1. What is the lifespan of a digitmap on a termination? Deos
>> it have anything  to do with what context (Null/Non-Null)
>> termination is in when the digit map  is defined fo the termination?
>
>[PTT]
>The basic rule for digit maps specified for an individual termination or a
>group of terminations is that stated in the first paragraph of section
>6.2.4:
><quote>
>If not provisioned otherwise, all descriptors except TerminationState and
>LocalControl default to empty/"no value" when a Termination is first created
>or returned to the null Context.
></quote>

Kris> Thanks for the clarification. I have another doubt now. What happens when MGC sets a new value for a provisioned Digit map on a Termid, and later sends an empty Digit map Desc with the same name for that Termination Id ?
Assuming the physical Termination context (Null/Non-Null) is not changed during this process.
What's the expected value for that digit map if an event Descriptor is received after this ? Should the provisioned value be used or an error be returned  assuming that there is no such digit map defined for the Termination ?
Should be the behaviour be different when the Termination is in Null/Non-Null context?
One of the arguments can be that since the default/provisioned values are restored only when a termination returns to the Null context, an error should be returned for any command having such an event Descriptor as the context has not changed yet. But then there is no way and MGC can get the provisioned value for the digit map through an audit until the Termination returns back to Null context.
Would like to know other list member's opinion about it.

>Provisioned digit maps persist for the life of the termination.  Digit maps
>defined on ROOT persist until deleted.
>

Kris> ROOT termination is different from the physical terminations in that it does not any context associated with it. So what happens in a scenario like above where MGC overrides the provisioned digit map value for the termination and later deletes the definition by sending an empty digit map desc for that termination with the same name. Since ROOT does not has a context associated with, above mentioned Sec 6.2.4 text does not apply to it.
So should the provisioned value for the digit map be restored or the digit map be deleted (and provisioned value be gone until provisioned again)?

>>
>>    2.  On the deletion of a ephemeral termination, Is it
>> required to remove all  the digitmap definitions, which are
>> associated with this termination.
>
>[PTT]
>Only if they were defined for this termination alone.
>
>>
>>  3. When a parmanent termination moves to NULL Context, will
>> it retain all  the digitmap defined on it(when it was in the
>> context), or will it retain
>>  only the default(/provisioned) digitmap definitions(if any)
>> on this  termination?
>
>[PTT] See 1. above.
>
>>
>>  Are DigMaps defined while termId is in Null context treated
>> as default values  which are restored when the termIf returns
>> to NULL context.
>
>[PTT] No, because of the rule quoted above.  The rule is perhaps too broad
>and should have made more exceptions, but it's done now.
>>
>>
>>
>>  Thanks in advance,
>>
>>  kris
>>
>>
>>
>> Great Gift Idea!  FREE cell phone, internet ready at Lycos Marketplace
>>  http://www.inphonic.lycos.com/redirect.asp?referringpage=www.lycosd1
>>
>


Get FREE Email/Voicemail with 15MB at Lycos Communications at http://comm.lycos.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec 14 11:00:13 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18508
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 14 Dec 2000 11:00:13 -0500 (EST)
Received: from standards (47.234.32.16:2704) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2B55@standards.nortelnetworks.com>; Thu, 14 Dec 2000 10:40:39 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 12706 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 10:40:39 -0500
Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC2B54@standards.nortelnetworks.com>; Thu, 14 Dec 2000
          10:40:38 -0500
Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by
          ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA06905
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 14 Dec 2000 10:58:41
          -0500 (EST)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by
          ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id KAA06897
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 14 Dec 2000 10:58:41
          -0500 (EST)
Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA25893; Thu, 14 Dec
          2000 10:58:38 -0500
Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id
          KAA25890; Thu, 14 Dec 2000 10:58:36 -0500
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <200012140042.AA35586368@mail.packetizer.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3A38EDDA.7035F209@lucent.com>
Date:         Thu, 14 Dec 2000 10:57:14 -0500
Reply-To: Troy Cauble <troy@bell-labs.com>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Troy Cauble <troy@LUCENT.COM>
Subject:      Re: context-free?
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Paul Long wrote:
>
> Troy,
>
> On what do you base your answer? Is this stated anywhere or is this simply your opinion? Context-dependent grammars are usually more difficult to parse... correctly. :-)

[TROY]
It is not stated anywhere.  That's an implementation detail.
It's the opinion of someone who's written a parser (me).
Your example below demonstrates the problem.  NAME and other
relatively freeform value tokens are indistinguishable from
keyword tokens such as AddToken without positional context.


>
> If you are right, I am concerned that those implementations that do not use a simple, most-likely hand-coded, predictive parser but instead use a parser generator where the lexer and parser are separate, e.g., lex/yacc, risk incorrect parsing due to the uncoupling between these two components. The reason is that most programming languages are context-free (C, C++, and Pascal are context-free; PL/I is not) so most implementors presumably have more experience parsing context-free grammars, e.g., programming languages, than context-dependent grammars, such as our Megaco text encoding. Unless implementors take special care to pass the context from the parser back to the lexer, e.g., by having yacc actions shift between lex states, their products will most likely parse


[TROY]
That is a concern for people using lex/yacc.  But they'll probably
see the problems before they finish, if not before they start.

I did successfully use bison & flex.  I won't tell all my secrets
but I'll give one hint:  Be careful with that concept of passing
"context from the parser back to the lexer" as yacc and bison are
*lookahead* parsers.

I would guess that others have worked around this issue with
parser generators too.  Even though the grammar is context-dependent,
for me, parser generators were too useful to do without.

-troy


>
>     A = A { M { L { } } }
>
> incorrectly as
>
>     AddToken EQUAL AddToken LBRKT ...
> or
>     NAME EQUAL NAME LBRKT ...
>
> rather than
>
>     AddToken EQUAL NAME LBRKT ...
>
> This is just a head-up for implementors to make sure that your parser will handle the Megaco ABNF as a context-_dependent_ grammar and to add test cases like the above as a test case to assure correctness.
>
> Paul Long
> ipDialog, Inc.
>
> ---------- Original Message ----------------------------------
> From: Troy Cauble <troy@LUCENT.COM>
> Reply-To: Troy Cauble <troy@bell-labs.com>
> Date:         Wed, 13 Dec 2000 19:18:06 -0500
>
> >Paul Long wrote:
> >>
> >> Does the text encoding use a context-free grammar? This cannot be discerned
> >> from the ABNF. For example, does "A" always represent the AddToken and never
> >> a name, e.g., a digitMapName?
> >>
> >> Paul Long
> >> ipDialog, Inc.
> >
> >No.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec 14 11:16:28 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21992
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 14 Dec 2000 11:16:27 -0500 (EST)
Received: from standards (47.234.32.16:2704) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2BC4@standards.nortelnetworks.com>; Thu, 14 Dec 2000 10:56:47 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 12788 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 10:56:47 -0500
Received: from mail.winsocket.com (sdsl-216-46-65-3.dsl.nyc.megapath.net) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC2B95@standards.nortelnetworks.com>; Thu, 14 Dec 2000
          10:46:47 -0500
Received: from localhost.localdomain [24.93.41.178] by mail.winsocket.com
          (SMTPD32-6.04) id AFA11F20152; Thu, 14 Dec 2000 11:04:49 -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.50.4522.1200
Message-ID:  <NEBBIELHMLDIACLLJHCNKEIDCHAA.plong@packetizer.com>
Date:         Thu, 14 Dec 2000 10:04:49 -0600
Reply-To: plong@ipdialog.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Paul Long <plong@PACKETIZER.COM>
Subject:      case
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <200012140042.AA35586368@mail.packetizer.com>
Content-Transfer-Encoding: 7bit

(I am fairly new to the list, so my apologies of this has already been
discussed.)

I noticed this in the 1st-interop report:

   "3. There was confusion on case sensitivity.  Consensus is that the
      Megaco language, including tokens, event names, signal names,
      parameter names, enumeration values, etc. are NOT case sensitive.
      Attention was noted that values in quotations may be case
      sensitive, and that SDP is case sensitive in most circumstances."

So does this mean that the Megaco ABNF is incorrect? For example, instead of

   AddToken                   = ("Add"                   / "A")

should it be replaced by the following?

   A                          = ("A" / "a")
   B                          = ("B" / "b")
   C                          = ("C" / "c")
   D                          = ("D" / "d")
   ...
   Z                          = ("Z" / "z")

   AddToken                   = ((A D D) / A)

IOW, are, for example, "Add", "ADD", "aDd", "add", "A", and "a" all
synonyms?

Paul Long
ipDialog, Inc.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec 14 11:44:50 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28833
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 14 Dec 2000 11:44:50 -0500 (EST)
Received: from standards (47.234.32.16:2704) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2C13@standards.nortelnetworks.com>; Thu, 14 Dec 2000 11:25:06 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 12942 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 11:25:06 -0500
Received: from mail.winsocket.com (sdsl-216-46-65-3.dsl.nyc.megapath.net) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC2C08@standards.nortelnetworks.com>; Thu, 14 Dec 2000
          11:15:06 -0500
Received: from localhost.localdomain [24.93.41.178] by mail.winsocket.com
          (SMTPD32-6.04) id A64427E0140; Thu, 14 Dec 2000 11:33:08 -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.50.4522.1200
Message-ID:  <NEBBIELHMLDIACLLJHCNMEIECHAA.plong@packetizer.com>
Date:         Thu, 14 Dec 2000 10:33:08 -0600
Reply-To: plong@ipdialog.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Paul Long <plong@PACKETIZER.COM>
Subject:      Re: context-free?
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <3A38EDDA.7035F209@lucent.com>
Content-Transfer-Encoding: 7bit

Troy,

Thanks for your reply.

Yes, I am aware of the look-ahead problem you mention. I've had to deal with
it in other grammars. The problem is that if the implementor is not careful,
by the time the context is recognized in yacc, the lexer may have already
recognized and classified the next lexeme via look-ahead before the parser
has had a chance to tell the lexer to use different rules for this context.

I think it should be explicitly stated in the spec that this is a
context-dependent grammar and that as a result there are no reserved
keywords. How about adding the following after the single sentence at the
beginning of B.2/RFC3015?

"The syntax SHALL be context-dependent. As a result, there SHALL be no
reserved keywords. For example, "Add" can be the AddToken or a NAME
depending on the context in which it occurs."

Paul Long
ipDialog, Inc.

-----Original Message-----
From: Media Gateway Control (megaco)
[mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Troy Cauble
Sent: Thursday, December 14, 2000 9:57 AM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: context-free?


Paul Long wrote:
>
> Troy,
>
> On what do you base your answer? Is this stated anywhere or is this simply
your opinion? Context-dependent grammars are usually more difficult to
parse... correctly. :-)

[TROY]
It is not stated anywhere.  That's an implementation detail.
It's the opinion of someone who's written a parser (me).
Your example below demonstrates the problem.  NAME and other
relatively freeform value tokens are indistinguishable from
keyword tokens such as AddToken without positional context.


>
> If you are right, I am concerned that those implementations that do not
use a simple, most-likely hand-coded, predictive parser but instead use a
parser generator where the lexer and parser are separate, e.g., lex/yacc,
risk incorrect parsing due to the uncoupling between these two components.
The reason is that most programming languages are context-free (C, C++, and
Pascal are context-free; PL/I is not) so most implementors presumably have
more experience parsing context-free grammars, e.g., programming languages,
than context-dependent grammars, such as our Megaco text encoding. Unless
implementors take special care to pass the context from the parser back to
the lexer, e.g., by having yacc actions shift between lex states, their
products will most likely parse


[TROY]
That is a concern for people using lex/yacc.  But they'll probably
see the problems before they finish, if not before they start.

I did successfully use bison & flex.  I won't tell all my secrets
but I'll give one hint:  Be careful with that concept of passing
"context from the parser back to the lexer" as yacc and bison are
*lookahead* parsers.

I would guess that others have worked around this issue with
parser generators too.  Even though the grammar is context-dependent,
for me, parser generators were too useful to do without.

-troy


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec 14 11:56:44 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00604
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 14 Dec 2000 11:56:43 -0500 (EST)
Received: from standards (47.234.32.16:2704) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2C44@standards.nortelnetworks.com>; Thu, 14 Dec 2000 11:37:14 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 12976 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 11:37:14 -0500
Received: from topaz.3com.com by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBC2C22@standards.nortelnetworks.com>; Thu, 14 Dec 2000 11:27:12
          -0500
Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com
          (Switch-2.0.1/Switch-2.0.1) with ESMTP id eBEGiN018732; Thu, 14 Dec
          2000 08:44:24 -0800 (PST)
Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM
          [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with
          SMTP id eBEGjF309100; Thu, 14 Dec 2000 08:45:15 -0800 (PST)
Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7  (934.1 12-30-1999))
          id 882569B5.005C3399 ; Thu, 14 Dec 2000 08:47:05 -0800
X-Lotus-FromDomain: 3COM
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <882569B5.005C3002.00@hqoutbound.ops.3com.com>
Date:         Thu, 14 Dec 2000 10:44:45 -0600
Reply-To: Natarajan_Kalpathy@3COM.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Natarajan Kalpathy <Natarajan_Kalpathy@3COM.COM>
Subject:      Re: Question on Keep Alives
X-To:         "Rosen, Brian" <Brian.Rosen@marconi.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Brian ,

what will be the Service change Method for the "noop" case ??.

Also at this point i am wondering if any one has defined a Keep alive Package or
is it some event within the root or generic package ???. Where can i get
reference to it ??

thanks in advance,
Natarajan




"Rosen, Brian" <Brian.Rosen@marconi.com> on 12/13/2000 05:46:53 PM

Sent by:  "Rosen, Brian" <Brian.Rosen@marconi.com>


To:   Natarajan Kalpathy/MW/US/3Com, MEGACO@STANDARDS.NORTELNETWORKS.COM
cc:
Subject:  RE: Question on Keep Alives



There is no need to do this.
The MGC can do an Audit if it doesn't see any traffic from the MGC for
a while

The MG can do a noop ServiceChange if it doesn't see any traffic from
the MG for a while.

Since there is an acceptable mechanism now, we should not add another.

Brian

> -----Original Message-----
> From: Natarajan Kalpathy [mailto:Natarajan_Kalpathy@3COM.COM]
> Sent: Wednesday, December 13, 2000 5:25 PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Question on Keep Alives
>
>
> This question is regarding the keep alives between MGC and MG.
>
> why dont we use Service change Command for Keep alive
> mechanism . We can extend
> the Service change method to include
> Keep Alive Method. The advantage being :-
>
> 1) The polling mechanism can either be at MGC or MG . (i-e it
> can be provisioned
> to exist either at MGC or MG)
> 2) If we Use Notify then there are 4 Msgs going back and
> forth between MGC and
> MG for each keep alive interval.
>
> MODIFY(Event descriptor = KEEP ALIVE);
> MODIFTRSP();
>
> NOTIFY(KEEP ALIVE)
> NOTIFYREPLY()
>
> regards,
> Natarajan
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec 14 12:52:10 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07457
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 14 Dec 2000 12:52:10 -0500 (EST)
Received: from standards (47.234.32.16:3811) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2C9E@standards.nortelnetworks.com>; Thu, 14 Dec 2000 12:32:35 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13130 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 12:32:35 -0500
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC2C9D@standards.nortelnetworks.com>; Thu, 14 Dec 2000 12:32:34
          -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id MAA20788; Thu, 14 Dec 2000 12:50:33 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com
          (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by
          mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA18544;
          Thu, 14 Dec 2000 12:50:36 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <Y7B34FFS>; Thu, 14 Dec 2000 12:50:34 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF01A6EBA2@whq-msgusr-02.pit.comms.marconi.com>
Date:         Thu, 14 Dec 2000 12:50:32 -0500
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: case
X-To:         "plong@ipdialog.com" <plong@ipdialog.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

I am confused.  The case in any Megaco token EXCEPT IN SDP is not
important, A, a, Add, ADD,AdD,aDd,... are all the Add token.
With that rule, the production, as written is correct, and a parser
should accept A,a, Add, ADD, AdD.... as the Add token.

ABNF never was explicit enough to capture this well without
tortuous productions.  Thus we have statements in the front
of the grammar, we have notes about "at most once", etc.

Brian

> -----Original Message-----
> From: Paul Long [mailto:plong@PACKETIZER.COM]
> Sent: Thursday, December 14, 2000 11:05 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: case
>
>
> (I am fairly new to the list, so my apologies of this has already been
> discussed.)
>
> I noticed this in the 1st-interop report:
>
>    "3. There was confusion on case sensitivity.  Consensus is that the
>       Megaco language, including tokens, event names, signal names,
>       parameter names, enumeration values, etc. are NOT case
> sensitive.
>       Attention was noted that values in quotations may be case
>       sensitive, and that SDP is case sensitive in most
> circumstances."
>
> So does this mean that the Megaco ABNF is incorrect? For
> example, instead of
>
>    AddToken                   = ("Add"                   / "A")
>
> should it be replaced by the following?
>
>    A                          = ("A" / "a")
>    B                          = ("B" / "b")
>    C                          = ("C" / "c")
>    D                          = ("D" / "d")
>    ...
>    Z                          = ("Z" / "z")
>
>    AddToken                   = ((A D D) / A)
>
> IOW, are, for example, "Add", "ADD", "aDd", "add", "A", and "a" all
> synonyms?
>
> Paul Long
> ipDialog, Inc.
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec 14 12:57:03 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08048
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 14 Dec 2000 12:57:02 -0500 (EST)
Received: from standards (47.234.32.16:3811) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2CBB@standards.nortelnetworks.com>; Thu, 14 Dec 2000 12:37:18 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13169 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 12:37:18 -0500
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC2CBA@standards.nortelnetworks.com>; Thu, 14 Dec 2000 12:37:18
          -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id MAA21238; Thu, 14 Dec 2000 12:55:17 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com
          (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by
          mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id MAA19777;
          Thu, 14 Dec 2000 12:55:20 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <Y7B34FNZ>; Thu, 14 Dec 2000 12:55:18 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF01A6EBA3@whq-msgusr-02.pit.comms.marconi.com>
Date:         Thu, 14 Dec 2000 12:55:09 -0500
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: context-free?
X-To:         Paul Long <plong@PACKETIZER.COM>
X-cc:         Troy Cauble <troy@bell-labs.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

It was not brought up, or if it was, it was forgotten.

If we had discussed it, I would have tried to make it context free,
by disallowing explicit language tokens as other identifiers, and
I would have gotten arguments from some who think that they must
have complete freedom to define termination.

Given where we are, we have to make it context dependent.

Brian

> -----Original Message-----
> From: Troy Cauble [mailto:troy@LUCENT.COM]
> Sent: Thursday, December 14, 2000 10:57 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: context-free?
>
>
> Paul Long wrote:
> >
> > Troy,
> >
> > On what do you base your answer? Is this stated anywhere or
> is this simply your opinion? Context-dependent grammars are
> usually more difficult to parse... correctly. :-)
>
> [TROY]
> It is not stated anywhere.  That's an implementation detail.
> It's the opinion of someone who's written a parser (me).
> Your example below demonstrates the problem.  NAME and other
> relatively freeform value tokens are indistinguishable from
> keyword tokens such as AddToken without positional context.
>
>
> >
> > If you are right, I am concerned that those implementations
> that do not use a simple, most-likely hand-coded, predictive
> parser but instead use a parser generator where the lexer and
> parser are separate, e.g., lex/yacc, risk incorrect parsing
> due to the uncoupling between these two components. The
> reason is that most programming languages are context-free
> (C, C++, and Pascal are context-free; PL/I is not) so most
> implementors presumably have more experience parsing
> context-free grammars, e.g., programming languages, than
> context-dependent grammars, such as our Megaco text encoding.
> Unless implementors take special care to pass the context
> from the parser back to the lexer, e.g., by having yacc
> actions shift between lex states, their products will most
> likely parse
>
>
> [TROY]
> That is a concern for people using lex/yacc.  But they'll probably
> see the problems before they finish, if not before they start.
>
> I did successfully use bison & flex.  I won't tell all my secrets
> but I'll give one hint:  Be careful with that concept of passing
> "context from the parser back to the lexer" as yacc and bison are
> *lookahead* parsers.
>
> I would guess that others have worked around this issue with
> parser generators too.  Even though the grammar is context-dependent,
> for me, parser generators were too useful to do without.
>
> -troy
>
>
> >
> >     A = A { M { L { } } }
> >
> > incorrectly as
> >
> >     AddToken EQUAL AddToken LBRKT ...
> > or
> >     NAME EQUAL NAME LBRKT ...
> >
> > rather than
> >
> >     AddToken EQUAL NAME LBRKT ...
> >
> > This is just a head-up for implementors to make sure that
> your parser will handle the Megaco ABNF as a
> context-_dependent_ grammar and to add test cases like the
> above as a test case to assure correctness.
> >
> > Paul Long
> > ipDialog, Inc.
> >
> > ---------- Original Message ----------------------------------
> > From: Troy Cauble <troy@LUCENT.COM>
> > Reply-To: Troy Cauble <troy@bell-labs.com>
> > Date:         Wed, 13 Dec 2000 19:18:06 -0500
> >
> > >Paul Long wrote:
> > >>
> > >> Does the text encoding use a context-free grammar? This
> cannot be discerned
> > >> from the ABNF. For example, does "A" always represent
> the AddToken and never
> > >> a name, e.g., a digitMapName?
> > >>
> > >> Paul Long
> > >> ipDialog, Inc.
> > >
> > >No.
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec 14 13:01:50 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08641
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 14 Dec 2000 13:01:50 -0500 (EST)
Received: from standards (47.234.32.16:3811) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2CDA@standards.nortelnetworks.com>; Thu, 14 Dec 2000 12:42:13 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13209 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 12:42:13 -0500
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC2CD9@standards.nortelnetworks.com>; Thu, 14 Dec 2000 12:42:13
          -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id NAA21636; Thu, 14 Dec 2000 13:00:14 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com
          (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by
          mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA21007;
          Thu, 14 Dec 2000 13:00:17 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <Y7B34FVS>; Thu, 14 Dec 2000 13:00: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:  <4FBEA8857476D311A03300204840E1CF01A6EBA4@whq-msgusr-02.pit.comms.marconi.com>
Date:         Thu, 14 Dec 2000 13:00:13 -0500
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: Question on Keep Alives
X-To:         "Natarajan_Kalpathy@3com.com" <Natarajan_Kalpathy@3com.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Restart on a termination already in service.

There is no package, and I don't think there needs to be.

Brian

> -----Original Message-----
> From: Natarajan_Kalpathy@3com.com [mailto:Natarajan_Kalpathy@3com.com]
> Sent: Thursday, December 14, 2000 11:45 AM
> To: Rosen, Brian
> Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: RE: Question on Keep Alives
>
>
>
>
> Brian ,
>
> what will be the Service change Method for the "noop" case ??.
>
> Also at this point i am wondering if any one has defined a
> Keep alive Package or
> is it some event within the root or generic package ???.
> Where can i get
> reference to it ??
>
> thanks in advance,
> Natarajan
>
>
>
>
> "Rosen, Brian" <Brian.Rosen@marconi.com> on 12/13/2000 05:46:53 PM
>
> Sent by:  "Rosen, Brian" <Brian.Rosen@marconi.com>
>
>
> To:   Natarajan Kalpathy/MW/US/3Com,
> MEGACO@STANDARDS.NORTELNETWORKS.COM
> cc:
> Subject:  RE: Question on Keep Alives
>
>
>
> There is no need to do this.
> The MGC can do an Audit if it doesn't see any traffic from the MGC for
> a while
>
> The MG can do a noop ServiceChange if it doesn't see any traffic from
> the MG for a while.
>
> Since there is an acceptable mechanism now, we should not add another.
>
> Brian
>
> > -----Original Message-----
> > From: Natarajan Kalpathy [mailto:Natarajan_Kalpathy@3COM.COM]
> > Sent: Wednesday, December 13, 2000 5:25 PM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Question on Keep Alives
> >
> >
> > This question is regarding the keep alives between MGC and MG.
> >
> > why dont we use Service change Command for Keep alive
> > mechanism . We can extend
> > the Service change method to include
> > Keep Alive Method. The advantage being :-
> >
> > 1) The polling mechanism can either be at MGC or MG . (i-e it
> > can be provisioned
> > to exist either at MGC or MG)
> > 2) If we Use Notify then there are 4 Msgs going back and
> > forth between MGC and
> > MG for each keep alive interval.
> >
> > MODIFY(Event descriptor = KEEP ALIVE);
> > MODIFTRSP();
> >
> > NOTIFY(KEEP ALIVE)
> > NOTIFYREPLY()
> >
> > regards,
> > Natarajan
> >
>
>
>
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec 14 13:20:57 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10920
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 14 Dec 2000 13:20:57 -0500 (EST)
Received: from standards (47.234.32.16:3811) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2D02@standards.nortelnetworks.com>; Thu, 14 Dec 2000 13:01:22 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13261 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 13:01:22 -0500
Received: from sapphire.int.ipverse.com (w067.z208037018.sjc-ca.dsl.cnc.net) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC2D01@standards.nortelnetworks.com>; Thu, 14 Dec 2000
          13:01:21 -0500
Received: from matt.ipverse.com (ietf.207.137.72.197.tx.verio.net
          [207.137.72.197]) by sapphire.int.ipverse.com with SMTP (Microsoft
          Exchange Internet Mail Service Version 5.5.2650.21) id XNX7N5LP; Thu,
          14 Dec 2000 10:19:26 -0800
X-Sender: matt@ipverse.com@pop3.ipverse.com
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID:  <5.0.2.1.2.20001214101355.02609e80@pop3.ipverse.com>
Date:         Thu, 14 Dec 2000 10:19:24 -0800
Reply-To: Matt Holdrege <matt@IPVERSE.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Matt Holdrege <matt@IPVERSE.COM>
Subject:      MIB notes from San Diego
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Go here http://www.net-standards.org/MEGACO-mib.ppt for the MIB slides from
the meeting...


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec 14 13:24:48 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11363
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 14 Dec 2000 13:24:46 -0500 (EST)
Received: from standards (47.234.32.16:3811) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2D12@standards.nortelnetworks.com>; Thu, 14 Dec 2000 13:03:34 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13251 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 13:03:34 -0500
Received: from zrchh190 (47.158.65.22:59431) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC2CFA@standards.nortelnetworks.com>; Thu, 14 Dec 2000 12:53:34
          -0500
Received: from zrtps06s.us.nortel.com by zrchh190; Thu, 14 Dec 2000 12:12:44
          -0600
Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Thu, 14 Dec
          2000 13:11:09 -0500
Received: from zrtpd00x.us.nortel.com ([47.140.202.32]) by
          zrtpd004.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2652.39) id YMLK0CJ3; Thu, 14 Dec 2000 13:10:59
          -0500
Received: from americasm01.nt.com (brtphe34.us.nortel.com [47.202.35.89]) by
          zrtpd00x.us.nortel.com with SMTP (Microsoft Exchange Internet Mail
          Service Version 5.5.2652.39) id YN94TFVN; Thu, 14 Dec 2000 13:10:55
          -0500
X-Mailer: Mozilla 4.76 [en] (X11; U; HP-UX B.10.20 9000/778)
X-Accept-Language: en
MIME-Version: 1.0
References: <NEBBIELHMLDIACLLJHCNKEIDCHAA.plong@packetizer.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Orig: <kboyle@americasm01.nt.com>
X-Orig: <kboyle@nortelnetworks.com>
Message-ID:  <3A390D31.AA686D4E@americasm01.nt.com>
Date:         Thu, 14 Dec 2000 13:10:58 -0500
Reply-To: "Boyle, Kevin [NCRTP:3Z70:EXCH]" <kboyle@AMERICASM01.NT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Boyle, Kevin [NCRTP:3Z70:EXCH]" <kboyle@AMERICASM01.NT.COM>
Organization: Nortel Networks
Subject:      Re: case
X-To:         plong@ipdialog.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

RFC 2234 - Augmented BNF for Syntax Specifications: ABNF, states that ABNF is
case-insensitive.

To quote from section 2.3: Terminal Values:

"Literal text strings are interpreted as a concatenated set of printable
characters.

        NOTE:     ABNF strings are case-insensitive and the character set for
these strings is us-ascii.

   Hence:

        rulename = "abc"

   and:

        rulename = "aBc"

   will match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC" and "ABC".

                To specify a rule which IS case SENSITIVE, specify the
characters individually."

Kevin

Paul Long wrote:

> (I am fairly new to the list, so my apologies of this has already been
> discussed.)
>
> I noticed this in the 1st-interop report:
>
>    "3. There was confusion on case sensitivity.  Consensus is that the
>       Megaco language, including tokens, event names, signal names,
>       parameter names, enumeration values, etc. are NOT case sensitive.
>       Attention was noted that values in quotations may be case
>       sensitive, and that SDP is case sensitive in most circumstances."
>
> So does this mean that the Megaco ABNF is incorrect? For example, instead of
>
>    AddToken                   = ("Add"                   / "A")
>
> should it be replaced by the following?
>
>    A                          = ("A" / "a")
>    B                          = ("B" / "b")
>    C                          = ("C" / "c")
>    D                          = ("D" / "d")
>    ...
>    Z                          = ("Z" / "z")
>
>    AddToken                   = ((A D D) / A)
>
> IOW, are, for example, "Add", "ADD", "aDd", "add", "A", and "a" all
> synonyms?
>
> Paul Long
> ipDialog, Inc.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec 14 14:15:10 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20151
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 14 Dec 2000 14:15:09 -0500 (EST)
Received: from standards (47.234.32.16:3029) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC2E22@standards.nortelnetworks.com>; Thu, 14 Dec 2000 13:55:33 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 13645 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 13:55:33 -0500
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC2E21@standards.nortelnetworks.com>; Thu, 14 Dec 2000 13:55:32
          -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id OAA27930; Thu, 14 Dec 2000 14:13:33 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com
          (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by
          mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA09232;
          Thu, 14 Dec 2000 14:13:37 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <Y7B34JWC>; Thu, 14 Dec 2000 14:13:35 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF01A6EBAC@whq-msgusr-02.pit.comms.marconi.com>
Date:         Thu, 14 Dec 2000 14:13:30 -0500
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: context-free?
X-To:         "plong@ipdialog.com" <plong@ipdialog.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Sure.  What we do at the moment is to put it in the "Implementors Guide"
When we reissue the RFC, we will put it in there.

Brian

> -----Original Message-----
> From: Paul Long [mailto:plong@packetizer.com]
> Sent: Thursday, December 14, 2000 2:11 PM
> To: Rosen, Brian
> Subject: RE: context-free?
>
>
> What do you think about my proposal to state this in the
> spec? I don't think
> it is at all clear, and I'd be willing to bet that at least a
> few current
> implementations would choke on the example I gave.
>
> -----Original Message-----
> From: Media Gateway Control (megaco)
> [mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Rosen, Brian
> Sent: Thursday, December 14, 2000 11:55 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: context-free?
>
>
> It was not brought up, or if it was, it was forgotten.
>
> If we had discussed it, I would have tried to make it context free,
> by disallowing explicit language tokens as other identifiers, and
> I would have gotten arguments from some who think that they must
> have complete freedom to define termination.
>
> Given where we are, we have to make it context dependent.
>
> Brian
>
> > -----Original Message-----
> > From: Troy Cauble [mailto:troy@LUCENT.COM]
> > Sent: Thursday, December 14, 2000 10:57 AM
> > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: context-free?
> >
> >
> > Paul Long wrote:
> > >
> > > Troy,
> > >
> > > On what do you base your answer? Is this stated anywhere or
> > is this simply your opinion? Context-dependent grammars are
> > usually more difficult to parse... correctly. :-)
> >
> > [TROY]
> > It is not stated anywhere.  That's an implementation detail.
> > It's the opinion of someone who's written a parser (me).
> > Your example below demonstrates the problem.  NAME and other
> > relatively freeform value tokens are indistinguishable from
> > keyword tokens such as AddToken without positional context.
> >
> >
> > >
> > > If you are right, I am concerned that those implementations
> > that do not use a simple, most-likely hand-coded, predictive
> > parser but instead use a parser generator where the lexer and
> > parser are separate, e.g., lex/yacc, risk incorrect parsing
> > due to the uncoupling between these two components. The
> > reason is that most programming languages are context-free
> > (C, C++, and Pascal are context-free; PL/I is not) so most
> > implementors presumably have more experience parsing
> > context-free grammars, e.g., programming languages, than
> > context-dependent grammars, such as our Megaco text encoding.
> > Unless implementors take special care to pass the context
> > from the parser back to the lexer, e.g., by having yacc
> > actions shift between lex states, their products will most
> > likely parse
> >
> >
> > [TROY]
> > That is a concern for people using lex/yacc.  But they'll probably
> > see the problems before they finish, if not before they start.
> >
> > I did successfully use bison & flex.  I won't tell all my secrets
> > but I'll give one hint:  Be careful with that concept of passing
> > "context from the parser back to the lexer" as yacc and bison are
> > *lookahead* parsers.
> >
> > I would guess that others have worked around this issue with
> > parser generators too.  Even though the grammar is
> context-dependent,
> > for me, parser generators were too useful to do without.
> >
> > -troy
> >
> >
> > >
> > >     A = A { M { L { } } }
> > >
> > > incorrectly as
> > >
> > >     AddToken EQUAL AddToken LBRKT ...
> > > or
> > >     NAME EQUAL NAME LBRKT ...
> > >
> > > rather than
> > >
> > >     AddToken EQUAL NAME LBRKT ...
> > >
> > > This is just a head-up for implementors to make sure that
> > your parser will handle the Megaco ABNF as a
> > context-_dependent_ grammar and to add test cases like the
> > above as a test case to assure correctness.
> > >
> > > Paul Long
> > > ipDialog, Inc.
> > >
> > > ---------- Original Message ----------------------------------
> > > From: Troy Cauble <troy@LUCENT.COM>
> > > Reply-To: Troy Cauble <troy@bell-labs.com>
> > > Date:         Wed, 13 Dec 2000 19:18:06 -0500
> > >
> > > >Paul Long wrote:
> > > >>
> > > >> Does the text encoding use a context-free grammar? This
> > cannot be discerned
> > > >> from the ABNF. For example, does "A" always represent
> > the AddToken and never
> > > >> a name, e.g., a digitMapName?
> > > >>
> > > >> Paul Long
> > > >> ipDialog, Inc.
> > > >
> > > >No.
> >
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec 14 22:44:32 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA05673
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 14 Dec 2000 22:44:31 -0500 (EST)
Received: from standards (47.234.32.16:1741) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC3490@standards.nortelnetworks.com>; Thu, 14 Dec 2000 22:25:05 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15852 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 22:25:05 -0500
Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC348F@standards.nortelnetworks.com>; Thu, 14 Dec 2000
          22:25:05 -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 WAA12381
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 14 Dec 2000 22:43:09
          -0500 (EST)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by
          auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id WAA12373
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 14 Dec 2000 22:43:09
          -0500 (EST)
Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id WAA01761; Thu, 14 Dec
          2000 22:43:06 -0500
Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id
          WAA01758; Thu, 14 Dec 2000 22:43:04 -0500
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17-21mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3A399337.DFE81128@lucent.com>
Date:         Thu, 14 Dec 2000 22:42:47 -0500
Reply-To: Troy Cauble <troy@bell-labs.com>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Troy Cauble <troy@LUCENT.COM>
Subject:      MEGACO: MediaDescriptor question
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Shouldn't the streams element be OPTIONAL too?

   MediaDescriptor ::= SEQUENCE
   {

        termStateDescr  TerminationStateDescriptor OPTIONAL,
        streams         CHOICE
                {
                        oneStream       StreamParms,
                        multiStream     SEQUENCE OF StreamDescriptor
                },
        ...
   }

-troy


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec 14 22:48:05 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA06762
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 14 Dec 2000 22:48:05 -0500 (EST)
Received: from standards (47.234.32.16:1741) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC34A3@standards.nortelnetworks.com>; Thu, 14 Dec 2000 22:26:38 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 15877 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 14 Dec 2000 22:26:38 -0500
Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC34A0@standards.nortelnetworks.com>; Thu, 14 Dec 2000
          22:26:38 -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 WAA12966
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 14 Dec 2000 22:44:42
          -0500 (EST)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by
          auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id WAA12952
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 14 Dec 2000 22:44:42
          -0500 (EST)
Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id WAA01778; Thu, 14 Dec
          2000 22:44:39 -0500
Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id
          WAA01775; Thu, 14 Dec 2000 22:44:39 -0500
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17-21mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3A399396.E8C5B44C@lucent.com>
Date:         Thu, 14 Dec 2000 22:44:22 -0500
Reply-To: Troy Cauble <troy@bell-labs.com>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Troy Cauble <troy@LUCENT.COM>
Subject:      MEGACO: Descriptor order significance?
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

The Add, Move, and Modify commands each take several descriptor
arguments.  Both the ABNF and ASN.1 encodings happen to encode
these descriptors in lists of any order.

Is there any significance to the order of these descriptors?

-troy


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec 15 08:27:07 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04607
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 15 Dec 2000 08:27:06 -0500 (EST)
Received: from standards (47.234.32.16:4325) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC372A@standards.nortelnetworks.com>; Fri, 15 Dec 2000 8:07:09 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 16775 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Dec 2000 08:07:09 -0500
Received: from auemlsrv.firewall.lucent.com (auemail1.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC3729@standards.nortelnetworks.com>; Fri, 15 Dec 2000
          8:07:09 -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 IAA17851
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 15 Dec 2000 08:25:14
          -0500 (EST)
Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com
          [135.17.42.35]) by auemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3)
          with ESMTP id IAA17823 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>;
          Fri, 15 Dec 2000 08:25:14 -0500 (EST)
Received: by NJ7460EXCH002H with Internet Mail Service (5.5.2650.21) id
          <YCP3H1FM>; Fri, 15 Dec 2000 08:25:13 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <F38185D061EBD21185F10008C7F926CE04A61233@nj7460exch007u.ho.lucent.com>
Date:         Fri, 15 Dec 2000 08:25:11 -0500
Reply-To: "Griffeth, Nancy D (Nancy)" <nancyg@LUCENT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Griffeth, Nancy D (Nancy)" <nancyg@LUCENT.COM>
Subject:      Re: MEGACO: Descriptor order significance?
X-To:         Troy Cauble <troy@bell-labs.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Troy,

The standard says there is; in section 7.2:

"The descriptors SHALL be processed in the order in which they appear."

This creates a problem if an AuditDescriptor appears before certain other
descriptors.  For example, if an AuditDescriptor contains a mediaToken and
is followed by a MediaDescriptor with some under- or over-specified
parameters,
the requirements become inconsistent.  According to the requirement quoted
above, the location of the audit descriptor requires that the original
media descriptor be returned.

In Section 7.1.1, the following statement appears:

"Whenever a parameter is underspecified or overspecified, the descriptor
containing the value chosen by the responder is included as output from the
command."

So if the subsequent media descriptor has under- or over-specified
parameters,
the new media descriptor must be returned.  But the syntax allows only one
media
descriptor.

I posted to the list earlier about this problem, but there's been no reply.

Nancy


-----Original Message-----
From: Troy Cauble [mailto:troy@LUCENT.COM]
Sent: Thursday, December 14, 2000 10:44 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: MEGACO: Descriptor order significance?


The Add, Move, and Modify commands each take several descriptor
arguments.  Both the ABNF and ASN.1 encodings happen to encode
these descriptors in lists of any order.

Is there any significance to the order of these descriptors?

-troy


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec 15 14:16:59 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10869
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 15 Dec 2000 14:16:59 -0500 (EST)
Received: from standards (47.234.32.16:4901) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC3866@standards.nortelnetworks.com>; Fri, 15 Dec 2000 13:57:08 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17198 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Dec 2000 13:57:07 -0500
Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC3865@standards.nortelnetworks.com>; Fri, 15 Dec 2000
          13:57:07 -0500
Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by
          ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA25809
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 15 Dec 2000 14:15:09
          -0500 (EST)
Received: from teton.mh.lucent.com (h135-3-130-2.lucent.com [135.3.130.2]) by
          ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id OAA25799
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 15 Dec 2000 14:15:09
          -0500 (EST)
Received: from lucent.com (pctla [135.3.130.39]) by teton.mh.lucent.com
          (8.8.8+Sun/8.8.8) with ESMTP id OAA16376 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 15 Dec 2000 14:13:34
          -0500 (EST)
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------524975BB8A981B6F46D99DC8"
Message-ID:  <3A3A6E58.FAD317EF@lucent.com>
Date:         Fri, 15 Dec 2000 14:17:45 -0500
Reply-To: Terry L Anderson <tla@LUCENT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Terry L Anderson <tla@LUCENT.COM>
Organization: Lucent Technologies
Subject:      underspecifying and overspecifying SDP
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.
--------------524975BB8A981B6F46D99DC8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

We are looking at options for negotiating codecs:
1) MGC presents a list of SDP blocks with different m= lines for codecs
in Local of Add for first (ingress) MG.  The list would have to come
from provisioning or Union of all known to be supported by MGs.  MG
chooses and MGC sends single choice in Local and Remote of other end
(terminating).

? is it permissible for orig to return a (possibly shorter) list of
codecs acceptible to it, have the MGC present this list to other end to
choose?  7.1.8 says that MG is requested to "choose one or more
values".  This would be more like H.245 where the end that makes the
choice knows the list acceptible to other end as well as self.

2. MGC presents a single SDP block with underspecified m= line
    m=audio $ RTP/AVP $
and ingress fills in port AND codec.  This avoids the need for MGC to
have a list of possibles.  Again MGC presents this sole choice to other
end.

? again is it permissible for a MG to return multiple SDP blocks with
multiple acceptible codecs in response to such an underspecified single
block?  It is not clear to me whether "underspecification" can apply to
entire SDP or only to a line of the SDP.  Which is a "property"?

3. MGC presents an empty SDP block consisting of v=0 only.  Is this form
of underspecifying allowed?  MG then fills in all the lines of an SDP or
possibly multiple SDP blocks in reply.

MGC cannot omit Local as MG would not reply with a Local according to
spec.  MGC cannot send an empty Local as that implies release of
reserved resources.

--
------------------------------------------------------------
Terry L Anderson              mailto:tla@lucent.com
Tel:908.582.7013   Fax:908.582.6729
Pager:800.759.8352 pin 1704572   1704572@skytel.com
Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla


--------------524975BB8A981B6F46D99DC8
Content-Type: text/x-vcard; charset=us-ascii;
 name="tla.vcf"
Content-Description: Card for Terry L Anderson
Content-Disposition: attachment;
 filename="tla.vcf"
Content-Transfer-Encoding: 7bit

begin:vcard
n:Anderson;Terry L
tel;pager:800.759.8352 pin 1704572
tel;fax:908.582.6729
tel;work:908.582.7013
x-mozilla-html:TRUE
url:http://its.lucent.com/~tla
org:Lucent / InterNetworking Systems;VoIP Access Networks / Applications Group
version:2.1
email;internet:tla@lucent.com
title:DMTS
adr;quoted-printable:;;600 Mountain Av=0D=0ARm 2B-121;Murray Hill;NJ;07974;USA
note;quoted-printable:http://www.gti.net/tla  or http://teton.mh.lucent.com/~tla (Lucent internal)=0D=0A18E343126 / 10034134
x-mozilla-cpt:;-23792
fn:Terry L Anderson
end:vcard

--------------524975BB8A981B6F46D99DC8--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec 15 23:47:13 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14233
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 15 Dec 2000 23:47:13 -0500 (EST)
Received: from standards (47.234.32.16:1365) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC39B7@standards.nortelnetworks.com>; Fri, 15 Dec 2000 23:27:38 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 17650 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 15 Dec 2000 23:27:38 -0500
Received: from zrchh190 (47.158.65.22:37932) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC39B6@standards.nortelnetworks.com>; Fri, 15 Dec 2000 23:17:38
          -0500
Received: from smtprch1.nortel.com (actually erchg0j) by zrchh190; Fri, 15 Dec
          2000 22:37:04 -0600
Received: from zcard015.ca.nortel.com (actually zcard015) by
          smtprch1.nortel.com; Fri, 15 Dec 2000 22:35:35 -0600
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id
          <Y7QJ80MB>; Fri, 15 Dec 2000 23:35:26 -0500
X-Mailer: Internet Mail Service (5.5.2652.35)
X-Orig: <taylor@nortelnetworks.com>
Message-ID:  <28560036253BD41191A10000F8BCBD110328D990@zcard00g.ca.nortel.com>
Date:         Fri, 15 Dec 2000 23:35:23 -0500
Reply-To: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Taylor, Tom-PT [NORSE:B901:EXCH]" <taylor@AMERICASM01.NT.COM>
Subject:      Draft IETF49 Megaco Minutes
X-To:         scott bradner <sob@harvard.edu>, Allison Mankin <mankin@isi.edu>
X-cc:         ITU-SG16@MAILBAG.INTEL.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

The Megaco Working Group met on Wednesday morning, December 13.  Tom Taylor
[taylor@nortelnetworks.com] chaired.

1. Agenda Bashing

The proposed agenda was as sent to the list (6/12/2000) with two additions:
a brief presentation of work on Bearer Independent Call Control (BICC) and
the proposed H.248 packages resulting from it, and presentation of
draft-ietf-megaco-fmtdeterm-00.txt.  The agenda as proposed was accepted.

2. ITU-T Study Group 16 Status Report
=====================================

Tom Taylor provided an update on the status of work in Study Group 16.

He reported that the ITU-T has introduced a new alternative decision
procedure
 -- like Last Call
 -- if all issues not resolved, fall back on existing procedure.
Scott Bradner added that the purpose in part was to make it easier to
synchronize ITU-T and IETF decision processes.

At the Study Group 16 meeting of 13-17 November the following items were
decided under the old procedures:
Annex F: Call discrimination, FAX, text telephony
Annex G: User interface elements
Annex H: SCTP transport
Annex I: ATM transport
Annex J: Dynamic tone generation
Annex K: Announcements

In addition, the meeting approved the first issue of the H.248v1
Implementor's Guide.

Question 14/16 is now renamed Question 3/16 for the new Study Period.  Q.
3/16 now has in hand the following additional official work items relating
to H.248.  There is no date set yet for completion of these items, but the
two Annexes have been determined.
 -- H.248v2
 -- Annex L: Error codes and ServiceChange reasons
 -- Annex M: Advanced audio server

The following additional work items have been accepted, but are in an early
state of maturity:
 -- Annex N: load control package (APC-2000)
 -- Annex O: data transport on analogue lines
 -- SDL appendix (informative).  The contributors are looking for more help.
 -- H.324 package.

Finally, the following H.248v2 items accepted, either at the Portland
Rapporteur's meeting in August or at the November meeting:
 -- ServiceChange to indicate change of capabilities (APC-1911)
 -- Finer discrimination in audits (APC-1913)
 -- signal on ROOT.
The APC numbers refer to document numbers on the informal SG 16 FTP site
(ftp://standards.pictel.com/avc-site /<meeting place and date>)  Tom noted
that ITU-T versions are more like protocol extensions than protocol
modifications.  Successive versions are intended to be backwards compatible.

Tom asked a process question: do we republish decided material as
Informational or Standards Track?  If the latter, presumably IETF comments
go into the ITU-T Implementor's Guide.

Flemming Andreasen [fandreas@cisco.com] identified the matter of how the
IETF coordinates with the ITU-T in the development of H.248v2 as a major
issue.  This point should be considered in the rechartering discussion.
Scott Bradner advised that no clear resolution of this point had been
reached in discussions with Study Group 16 management.

Further process discussion elicited the view that decided items of interest
to the IETF should be taken through the complete IETF process and targeted
for Standards Track RFCs.  The list should decide which items should go this
route.  Scott Bradner instructed the Chair to get explicit permission from
the ITU-T TSB before republishing the decided material, since it is not
clear whether our agreement on H.248 extends beyond the initial protocol
document.

3. Completion Of Charter Items
==============================

(a) Megaco MIB
    ----------

Matt Holdrege [matt@IPVERSE.COM] provided a status report on the development
of the Megaco MIB.  He emphasized that the main purpose of the present draft
was to get objects on the table for discussion.  He estimated at least two
recycles before the draft is in reasonable shape.  He presented a long list
of detailed issues to be worked through. [Presentation will be attached to
published minutes].  There was no discussion at the meeting.

(b) NAS Package
    -----------

Tom Taylor briefly summarized the status of the NAS packages.  [Presentation
to be attached to final minutes.]  He pointed out that complementary work on
indication of TDM bearer capability remained to be done.  In his opinion
this would be an SDP extension in the spirit of the ATM SDP extension.  The
hum in favour of moving this work forward was practically imperceptible: it
is left to the list to decide.  The Chair will be soliciting comment from
the list on whether this should be a Standards Track item.


4. Well-Aged Package Drafts
   ========================

Michael Brown [C.Michael.Brown@nortelnetworks.com] presented all drafts
under this heading, as co-author.  (The presentation was actually
interrupted but is documented here as if it had proceeded according to
original plan.)

(a) draft-boyle-megaco-tonepkgs-01.txt
    ----------------------------------

This document provides a number of specialized tone packages.  [Presentation
will be attached to minutes.]  Michael noted that Study Group 11 (the BICC
group) had asked for an optional directionality parameter for tones and
announcements.  Its use is to direct signals inwards to the context; it
optimizes an operation which would otherwise require individual modification
of all of the other terminations in the context or treatment of an
announcement or tone source as a termination in its own right.  The authors
of draft-boyle-megaco-tonepkgs-01.txt propose to recycle the draft to
include this parameter.

Brian Rosen [Brian.Rosen@MARCONI.COM] expressed his view that the use of a
directionality parameter for signals should be approved on the list.  Glen
Freundlich [ggf@avaya.com] noted that Study Group 16 added such a parameter
to the new Annex K announcement package.

The meeting agreed that the directionality parameter discussion is required,
but otherwise the draft is ready for list Last Call.

(b) draft-boyle-megaco-alerting-00.txt
    ----------------------------------

This package provides capabilities related to CLASS signalling.  There is an
overlap in scope with the proposed Annex O, but the latter has a finer level
of detail which in Michael's opinion may result in timing difficulties.

Brian Rosen asked if there had been coordination of approach between this
work and automatic number identification (ANI/DNIS).  Michael responded that
the problems were similar, but not the same.

The meeting agreed that before this draft moves forward there should be a
discussion and resolution on the list of the respective content of this
draft and the SG 16 Annex O proposal.  Action: Chair to arrange for
publication of current draft of Annex O as an I-D to aid the discussion.

(c) draft-cornel-megaco-enhancedd-00.txt
    ------------------------------------

This draft defines an enhanced DTMF digit collection capability, designed
particularly for mid-call digit collection.  The package includes a modified
digit map completion event.

Scott Bradner noted with respect to this and previous items that
non-response is not enough to justify standardization.  The Chair must
solicit discussion if necessary before deciding to move forward.

(d) draft-scoggins-megaco-pktnetpkg-00.txt
    --------------------------------------

This package proposal is withdrawn in favour of packages included in the
Q.1950 (BICC) work.


5. ITU-T Study Group 11 BICC Status
   ================================

Greg Ratta [gratta@lucent.com], SG 11 Vice Chairman in the area of
IP-related signalling work, provided an introduction to Bearer Independent
Call Control work dealing with IP networks.  [Presentation charts will be
attached to official minutes.]  The presentation showed the basic
architecture and listed two sets of packages: those picked up directly from
H.248, and those developed by the BICC group specifically to suit their
needs.  The key architectural points are that call signalling is based on
ISUP, with modifications to support an abstract interface to the media
bearers.  The protocol interface between the call server and lower-layer
functions features a strict separation between bearer-related information
and media-related information.

Brian Rosen commented that he had read the BICC documents quickly and had
come away with the sense that they violated the spirit of the H.248
protocol.  He thought that SG 11 might need more H.248 expertise.  He looked
for a way to share our knowledge, with the intent of preserving a single
protocol.  Greg responded by recalling to Brian that Frame Relay, as an
example, eventually saw application far beyond its original conception.  He
was open to the use of channels for the exchange of information between the
two groups.  The time for Megaco to get involved is definitely now, given
that the documents have been determined and a final editing meeting has been
scheduled for the latter half of February.

Michael Ramalho [mramalho@cisco.com] seconded Brian's thoughts about the
pooling of knowledge.  However, he wondered why a project which seemed to be
aimed at reproducing SS7 in the IP network should aim beyond that by
emphasizing the separation between call control and bearer control.  Greg
responded that the main aim is to allow traditional networks to operate over
new transport.  The impetus for the call control/bearer control separation
comes from the mobile area.

Michael Brown noted that he had been somewhat involved in Study Group 11's
work on BICC.  The architecture forces transport of information differently
from how H.248 does it.  He raised the possibility that an alternative
architecture would allow H.248 to operate as usual.  He advised those
present that, besides draft Q.1950, they should look at draft Q.1990 and the
BICC requirements and architecture documents.  Q.1950 is the document which
Study Group 11 has just determined, and which will be the subject of the
February editing meeting.

Ian Rytina [ian.rytina@ericsson.com.au] warned that Megaco should not come
barging into the midst of the BICC work shouting "All wrong!" without
reflection.  Study Group 16 people have been involved in BICC almost from
the beginning.


6. ISDN
   ====

Bouwen Jan [jan.bouwen@alcatel.be] presented
draft-bouwen-megaco-isdn-bcp-00.txt, draft-bouwen-megaco-isdn-data-00.txt,
and draft-bouwen-megaco-isdn-pack-00.txt.  [Presentation to be attached to
official minutes.]  The content has not changed significantly from the
original draft, but it was broken into these three documents to make it
easier to understand.

Brian Rosen, commenting on the -isdn-pack draft, suggested that we need
group consensus on the use of signals vs. the use of properties for
management-type functions.  We should decide one way or the other and
enforce the chosen style in package definitions.  Action is on the Chair to
initiate list discussion.  Related items in Study Group 16 are the proposed
signal on ROOT for heartbeat messages, and proposed audio segment management
operations in draft Annex M (Advanced Audio Server).

Brian saw the BCP as a necessary document.  However, naming patterns should
go into profiles.  He also wondered whether the modem descriptor should be
used for D-channel data.  The basic feeling was that the drafts other than
the BCP document should move forward on Standards Track, but only after
there had been more list discussion.  The Chair undertook to focus
discussion on the ISDN drafts in the coming week.

Peter Blatherwick [blather@nortelnetworks.com] wondered whether the BCP
document should actually be a profile.


7.  CAS Design Team Report
    ======================

Michael Brown reported.  draft-manyfolks-megaco-caspackage is on its way.
The interest in channel-associated signalling (CAS) is large; the design
team grew through word of mouth after it had been set up.

The team sees the need for the following packages:
 - Basic CAS
 - Robbed bit signalling (wink/seizure)
 - MF generation and detection
 - Operator services
The draft will be published shortly.  List comment is encouraged.


8. Other Proposals
   ===============

(a) draft-rosen-megaco-namepatterns-00.txt
    --------------------------------------

Brian Rosen presented.  The mechanism is intended to help control the volume
of information retrieved on audits.  The intent is that the MGC retrieve
this one property on ROOT, then walk through the patterns to retrieve
information on groups of terminations.

Tom Taylor noted that the mechanism allowed more precise designation than
the one in the proposed NASROOT package.  There is a need to reconcile the
latter with Brian's proposals.  Aside from the basic mechanism, a list
debate is needed on whether ROOT packages should be defined in the manner of
NASROOT to associate naming patterns with termination classes.  This relates
to the old problem of finding out about the MG's capabilities for ephemerals
before any of the latter have been created.

Michael Brown noted that the naming pattern in the MG may be purely physical
(e.g. shelf/slot), and may not relate to the type of card (hence the
termination class) provisioned there.

(b) draft-cutler-megaco-recvpkg-01.txt
    ----------------------------------

Wayne Cutler [wayne.cutler@marconi.com] presented.  The general intent is to
allow the MGC to store state against individual terminations on MGs to allow
a cleaner recovery from call failures.

Flemming Andreasen termed the proposal bizarre at first sight.  He asked
whether the data to be stored included call state.  Wayne indicated not, but
that the data would be call-related.  Flemming asked what would happen if
multiple MGCs were involved.  Wayne asked for clarification of whether
Flemming meant multiple MGCs acting as a single logical MGC.  Flemming
complained of lack of generality.  Brian Rosen stepped in to point out that
the proposal is general with respect to content.  Obviously a length limit
would be needed.  Scott Bradner noted that the author is simply asking for a
cookie mechanism.  The only concern is that it is defined too specifically.

Clearly a matter for further discussion on the list.

(c) draft-levy-megaco-mgdiscovery-01.txt
    ------------------------------------

Thomas LEVY [thomas.levy@ms.alcatel.fr] presented.  The draft is intended to
provide further information from the MG in support of load balancing.  He
reviewed the available alternatives and came up with a specific
recommendation.  Brian Rosen suggested that this work had the same time
frame as SDPng, and thus the latter is the preferred route to a solution.
Thomas responded that the expected incompatibility between SDP and SDPng
made it desirable to find a solution independent of either.  Scott Bradner
suggested that we check out other resource capability work being done in the
IETF.

(d) draft-ietf-megaco-fmtdeterm-00.txt
    ----------------------------------

The Chair overlooked this item as the meeting was running out of time.  It
will be taken to the list for Last Call (Informational).


9. Interoperability
   ================

Brian Rosen reported on the results of the August interoperability event and
gave some information on the next one.


10. Rechartering Discussion
    =======================

Scott Bradner led off discussion of the future of the Working Group by
saying that WGs normally have a finite life.  Working Groups are justified
when they need meeting time to discuss open issues.  He had not seen much
evidence of such discussion at this meeting -- only a series of
presentations.

Brian Rosen spoke of a need to continue our work on packages.  The lack of
controversy at the present meeting was because the packages presented were
well-baked.  He also saw the need for an official working group to provide
impedance to Study Group 16.  The WG itself should not be working on a new
version of Megaco -- only on packages.  Matt Holdrege picked up the argument
that Megaco is needed to provide legitimacy because the work it is involved
in reaches beyond the IETF.

Peter Blatherwick agreed that the group should continue its work on
packages.  He would also like to see more work on profiles, to provide rules
for profile definition, how to do "inheritance", whether the MG can support
multiple profiles at a time.  This item was intentionally deferred earlier
in the progress of WG, but there is serious risk of profiles getting out of
control.  Flemming Andreasen disagreed with this proposal.

Scott Bradner called for a show of hands on continuing the Working Group.
There were a fair number in favour of continuation and none in favour of
going dormant.  Scott instructed the Chair to take a draft charter to the
list.  The IESG might consider extension of the group's life, but the
charter must contain concrete deliverables.


Tom Taylor
Ph. +1 613 736 0961
taylor@nortelnetworks.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Dec 17 07:18:30 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08057
	for <megaco-archive@LISTS.IETF.ORG>; Sun, 17 Dec 2000 07:18:29 -0500 (EST)
Received: from standards (47.234.32.16:4950) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC3C21@standards.nortelnetworks.com>; 17 Dec 2000 6:58:26 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 18513 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 17 Dec 2000 06:58:26 -0500
Received: from mail.cn.prospectful.com (202.103.148.210:1331) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC3C20@standards.nortelnetworks.com>; 17 Dec 2000 6:48:25
          -0500
Received: from 1Cust54.tnt1.mia5.da.uu.net by mail.cn.prospectful.com with SMTP
          (Microsoft Exchange Internet Mail Service Version 5.0.1457.7) id
          XR676HGN; Fri, 1 Dec 2000 06:14:45 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset=unknown-8bit
Message-ID:  <MEGACO%2000121706582626@STANDARDS.NORTELNETWORKS.COM>
Date:         Sun, 17 Dec 2000 06:58:26 -0500
Reply-To: Younger@BDSM.AT
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Younger@BDSM.AT
Subject:      REVERSE the AGING PROCESS 10-20 Years!
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

HAVE YOU HEARD OF HUMAN GROWTH HORMONE (HGH)???

Released by your own pituitary gland, HGH starts
declining in your 20s, even more in your 30s and 40s,
eventually resulting in the shrinkage of major
organs-plus all other symptoms related to old age.

THIS CAN NOW BE REVERSED!!! IN THOUSANDS OF CLINICAL
STUDIES, HGH HAS BEEN SHOWN TO ACCOMPLISH THE FOLLOWING:

* Reduce Body Fat Without Dieting
   Build Lean Muscle WITHOUT EXERCISE!

* Enhance Sexual Performance

* Remove Wrinkles and Cellulite

* Lower Blood Pressure and improve Cholesterol Profile

* Improve Sleep, Vision and Memory

* Restore Hair Color and Growth

* Strengthen the Immune System

* Increase Energy and Cardiac Output

* Turn back your body's Biological Time Clock 10-20
   years in 6 months of usage !!!

You don't have to spend thousands of dollars on shots.
You don't have to spend the $139.00 per bottle that
HGH is selling for at some Clinics in the
United States.

For the next 30 Days, you can obtain a complete
one-month supply of our HGH releaser for our special
"New Customers" price of just $69.95 plus $6.00
shipping and handling. To ensure a constant supply and
to SAVE EVEN MORE, you can order with confidence
3 bottles of HGH and GET 1 FREE - that's just $209.85 for
4 bottles, plus $6.00 shipping and handling.
You SAVE $69.95! ORDER TODAY!

Payment Methods

You may FAX or Postal Mail Checks, MasterCard, Visa,
& American Express payments. Money Orders
are accepted only by Postal Mail.


Step 1: Place a check by your desired quanity.


______ 1 Bottle of HGH $69.95


______ 2 Bottles of HGH $131.90 ($65.95 a bottle)


______ 4 Bottles of HGH (Buy 3 get 1 FREE. SAVE $69.95) $209.85


Please add $6 shipping and handling for any size order.
[ Total cost including shipping & handling,
1 bottle=$75.95, 2 bottles=$137.90, 4 bottles=$215.85 ]

International shipping, please add $35 for any size order
[ Total cost including shipping & handling,
1 bottle=$104.95, 2 bottles=$166.90, 4 bottles=$244.85 ]
Foreign checks are not accepted.  Credit cards & international
money orders only.

Step 2: Place a check by your desired payment method
and complete fields if necessary.


_____Check or CHECK-BY-FAX [details below]


_____Money Order


_____American Express
Account Number__________________ Exp____/____

_____Visa
Account Number__________________ Exp____/____

_____MasterCard
Account Number__________________ Exp____/____


Please make your check or money order payable to
"Lion Sciences National".

Step 3: Please complete and print the following fields clearly.


Name ___________________________________________________


Address _________________________________________________


City ____________________________________________________


State ___________________________________________________


Zip _____________________________________________________


E-mail __________________________________________________


Signature _________________________________________________
[ required for check and credit card orders]



            Toll Free FAX Order Line: 1-800-940-6590

If faxing in your order, please state whether you require
a fax, email, or no confirmation at all.
Allow up to one day for confirmation, if requested.
FAX orders are processed immediately.

            Or, print & mail to:

Lion Sciences National
273 S. State Rd. 7  #193
Margate, FL 33068-5727


        ______________________________________________________


*CHECK BY FAX ORDERS: Complete the check as normal. Tape
the check in the area below. Below the check, clearly write
the check number, all numbers at the bottom of the check,
& your name. Tape the check below and fax the check to the
toll free FAX number above. Void the check. Our merchant
will electronically debit your account for the amount of
the check; your reference number for this transaction will
be your check number. Nothing could be safer & easier !

                          TAPE CHECK BELOW
















_____________________________________________________________

This is a one time mailing: Removal is automatic and no further
contact is necessary. Please Note: HGH is not intended to
diagnose, treat, cure or prevent any disease. The FDA has not
evaluated these statements.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Mon Dec 18 14:43:35 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14063
	for <megaco-archive@LISTS.IETF.ORG>; Mon, 18 Dec 2000 14:43:35 -0500 (EST)
Received: from standards (47.234.32.16:2520) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC404D@standards.nortelnetworks.com>; Mon, 18 Dec 2000 14:23:29 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 19917 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 18 Dec 2000 14:23:28 -0500
Received: from radvpost.us.radvision.com (38.150.216.6:32476) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC404C@standards.nortelnetworks.com>; Mon, 18 Dec 2000
          14:23:28 -0500
Received: by RADVPOST with Internet Mail Service (5.5.2650.21) id <ZD08VHAZ>;
          Mon, 18 Dec 2000 14:41: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:  <0D5BBF5D638DD4119E3400508BD9494524F87A@RADVPOST>
Date:         Mon, 18 Dec 2000 14:41:15 -0500
Reply-To: Dan Elbert <DElbert@RADVISION.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Dan Elbert <DElbert@RADVISION.COM>
Subject:      Re: underspecifying and overspecifying SDP
X-To:         Terry L Anderson <tla@LUCENT.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

1. Seems OK if ReserveGroup=True.
What happens after the other end chooses ?
Does the MGC send a Modify releasing all resources but the chosen one?

2. Again, seems like if ReserveGroup=True you should receive all the
alternatives in different SDP blocks.

3. I believe that this is mat not be legal in SDP. In any case the
interpretation would be "a session with no media". This will not do what you
want.

Dan Elbert
RADVISION

-----Original Message-----
From: Terry L Anderson [mailto:tla@LUCENT.COM]
Sent: Friday, December 15, 2000 2:18 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: underspecifying and overspecifying SDP


We are looking at options for negotiating codecs:
1) MGC presents a list of SDP blocks with different m= lines for codecs
in Local of Add for first (ingress) MG.  The list would have to come
from provisioning or Union of all known to be supported by MGs.  MG
chooses and MGC sends single choice in Local and Remote of other end
(terminating).

? is it permissible for orig to return a (possibly shorter) list of
codecs acceptible to it, have the MGC present this list to other end to
choose?  7.1.8 says that MG is requested to "choose one or more
values".  This would be more like H.245 where the end that makes the
choice knows the list acceptible to other end as well as self.

2. MGC presents a single SDP block with underspecified m= line
    m=audio $ RTP/AVP $
and ingress fills in port AND codec.  This avoids the need for MGC to
have a list of possibles.  Again MGC presents this sole choice to other
end.

? again is it permissible for a MG to return multiple SDP blocks with
multiple acceptible codecs in response to such an underspecified single
block?  It is not clear to me whether "underspecification" can apply to
entire SDP or only to a line of the SDP.  Which is a "property"?

3. MGC presents an empty SDP block consisting of v=0 only.  Is this form
of underspecifying allowed?  MG then fills in all the lines of an SDP or
possibly multiple SDP blocks in reply.

MGC cannot omit Local as MG would not reply with a Local according to
spec.  MGC cannot send an empty Local as that implies release of
reserved resources.

--
------------------------------------------------------------
Terry L Anderson              mailto:tla@lucent.com
Tel:908.582.7013   Fax:908.582.6729
Pager:800.759.8352 pin 1704572   1704572@skytel.com
Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Dec 19 00:59:56 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA25352
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 19 Dec 2000 00:59:55 -0500 (EST)
Received: from standards (47.234.32.16:1726) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC42BD@standards.nortelnetworks.com>; Tue, 19 Dec 2000 0:40:06 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 20762 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 19 Dec 2000 00:40:06 -0500
Received: from mailcity.com (fes-qout.whowhere.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC42BC@standards.nortelnetworks.com>; Tue, 19 Dec 2000
          0:40:05 -0500
Received: from Unknown/Local ([?.?.?.?]) by mailcity.com; Mon Dec 18 21:58:05
          2000
Mime-Version: 1.0
X-Sent-Mail: off
X-Mailer: MailCity Service
X-Sender-Ip: 12.40.232.2
Content-Type: text/plain; charset=us-ascii
Content-Language: en
Content-Transfer-Encoding: 7bit
Message-ID:  <MLADLIBLCFCCFAAA@mailcity.com>
Date:         Mon, 18 Dec 2000 21:58:05 -0800
Reply-To: kris_albert@lycos.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Kris Albert <kris_albert@lycos.com>
Organization: Lycos Communications  (http://comm.lycos.com:80)
Subject:      Fwd: Re: DigMap Related Questions
X-cc:         taylor@NORTELNETWORKS.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi Tom and List!
Can we assume that silence on the issue means the following consensus.

1. If a provisioned definition on a specific termination is overridden by an empty definition by MGC, while it is in (NULL/Non NULL) context, the digitmap becomes unavailable for the termination in that context even though the digitmap may have a provisioned value defined for the termination.
The provisioned value becomes "visible" only when the termination "returns" to NULL context.
2. In case of ROOT termination, the provisioned value can NEVER be restored once MGC overrides it with a new value. Even an empty value being set by MGC for that digitmap name does not restore the provisioned value and the digitmap becomes undefined for ROOT until set to a new (non-empty) value  by MGC/provisioning.

thanks
Kris

--------- Forwarded Message ---------

DATE: Thu, 14 Dec 2000 04:44:27
From: Kris Albert <kris_albert@LYCOS.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

 Hi Tom and List!
I have some new queries after Tom's response. Please see the interspersed queries as Kris>.

thanks,
Kris
--

On Fri, 8 Dec 2000 12:07:04
 Taylor, Tom-PT [NORSE:B901:EXCH] wrote:
>Hi.
>
>> -----Original Message-----
>> From: Kris Albert [mailto:kris_albert@LYCOS.COM]
>> Sent: Wednesday, December 06, 2000 12:17 AM
>> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
>> Subject: [MEGACO] DigMap Related Questions
>>
>>
>> Hi all,
>>       I have few questions related to the digitmaps
>>
>>  1. What is the lifespan of a digitmap on a termination? Deos
>> it have anything  to do with what context (Null/Non-Null)
>> termination is in when the digit map  is defined fo the termination?
>
>[PTT]
>The basic rule for digit maps specified for an individual termination or a
>group of terminations is that stated in the first paragraph of section
>6.2.4:
><quote>
>If not provisioned otherwise, all descriptors except TerminationState and
>LocalControl default to empty/"no value" when a Termination is first created
>or returned to the null Context.
></quote>

Kris> Thanks for the clarification. I have another doubt now. What happens when MGC sets a new value for a provisioned Digit map on a Termid, and later sends an empty Digit map Desc with the same name for that Termination Id ?
Assuming the physical Termination context (Null/Non-Null) is not changed during this process.
What's the expected value for that digit map if an event Descriptor is received after this ? Should the provisioned value be used or an error be returned  assuming that there is no such digit map defined for the Termination ?
Should be the behaviour be different when the Termination is in Null/Non-Null context?
One of the arguments can be that since the default/provisioned values are restored only when a termination returns to the Null context, an error should be returned for any command having such an event Descriptor as the context has not changed yet. But then there is no way and MGC can get the provisioned value for the digit map through an audit until the Termination returns back to Null context.
Would like to know other list member's opinion about it.

>Provisioned digit maps persist for the life of the termination.  Digit maps
>defined on ROOT persist until deleted.
>

Kris> ROOT termination is different from the physical terminations in that it does not any context associated with it. So what happens in a scenario like above where MGC overrides the provisioned digit map value for the termination and later deletes the definition by sending an empty digit map desc for that termination with the same name. Since ROOT does not has a context associated with, above mentioned Sec 6.2.4 text does not apply to it.
So should the provisioned value for the digit map be restored or the digit map be deleted (and provisioned value be gone until provisioned again)?

>>
>>    2.  On the deletion of a ephemeral termination, Is it
>> required to remove all  the digitmap definitions, which are
>> associated with this termination.
>
>[PTT]
>Only if they were defined for this termination alone.
>
>>
>>  3. When a parmanent termination moves to NULL Context, will
>> it retain all  the digitmap defined on it(when it was in the
>> context), or will it retain
>>  only the default(/provisioned) digitmap definitions(if any)
>> on this  termination?
>
>[PTT] See 1. above.
>
>>
>>  Are DigMaps defined while termId is in Null context treated
>> as default values  which are restored when the termIf returns
>> to NULL context.
>
>[PTT] No, because of the rule quoted above.  The rule is perhaps too broad
>and should have made more exceptions, but it's done now.
>>
>>
>>
>>  Thanks in advance,
>>
>>  kris
>>
>>
>>
>> Great Gift Idea!  FREE cell phone, internet ready at Lycos Marketplace
>>  http://www.inphonic.lycos.com/redirect.asp?referringpage=www.lycosd1
>>
>


Get FREE Email/Voicemail with 15MB at Lycos Communications at http://comm.lycos.com

--------- End Forwarded Message ---------



Get FREE Email/Voicemail with 15MB at Lycos Communications at http://comm.lycos.com


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Dec 19 03:49:49 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09530
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 19 Dec 2000 03:49:49 -0500 (EST)
Received: from standards (47.234.32.16:3833) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC4305@standards.nortelnetworks.com>; Tue, 19 Dec 2000 3:29:56 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 20860 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 19 Dec 2000 03:29:56 -0500
Received: from zmers013 (47.124.1.40:34416) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC4304@standards.nortelnetworks.com>; Tue, 19 Dec 2000 3:29:56
          -0500
Received: from tlhuph12.elex.co.il (actually ertpg1e0.us.nortel.com) by
          zmers013; Tue, 19 Dec 2000 03:47:59 -0500
Received: from tmx100.elex.co.il (tmx100.elex.co.il [141.226.8.254]) by
          tlhuph12.elex.co.il (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id KAA09617
          for <MEGACO@standards.nortelnetworks.com>; Tue, 19 Dec 2000 10:48:11
          +0200 (IST)
Received: from tl100h0c.elex.co.il by tmx100.elex.co.il (8.8.8+Sun/SMI-SVR4) id
          KAA17397; Tue, 19 Dec 2000 10:48:10 +0200 (IST)
Received: from tmx100.elex.co.il (rakefet@localhost [127.0.0.1]) by
          tl100h0c.elex.co.il with ESMTP (8.8.6 (PHNE_14041)/8.7.3) id KAA08076
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 19 Dec 2000 10:48:09
          +0200 (IST)
X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.10.20 9000/712)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3A3F20C8.E50DF9B8@tmx100.elex.co.il>
Date:         Tue, 19 Dec 2000 10:48:08 +0200
Reply-To: "Prozan, Rakefet [LOD:Telrad:SMTPPART]"              <rakefet.prozan@telrad.co.il>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Prozan, Rakefet [LOD:Telrad:SMTPPART]"              <rakefet.prozan@telrad.co.il>
Organization: Telrad Ltd.
Subject:      Error Descriptor Problems
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi all,

I have 2 questions regarding the errorDescriptor:

1) It is written in rfc3015.txt (page 61):

  " The TransactionReply includes
   the return values for the Commands that were executed successfully,
   and the Command and error descriptor for any Command that failed."

   So, I understand that if a command failed ,the reply will include the
 command token ,the TerminationID & the errorDescriptor.

  For instance, if there is an illegal parameter in one of the
  descriptors of an Add command, the reply  will look like:

  Add=55555{Error=455{Parameter illegal in this Descriptor}}.

  But on the other hand,the following definitions allow sending of
  other descriptors in the same command with the errorDescriptor:

ammsReply            = (AddToken / MoveToken / ModifyToken /
                           SubtractToken ) EQUAL TerminationID [ LBRKT
                           terminationAudit RBRKT ]

terminationAudit     = auditReturnParameter *(COMMA
                        auditReturnParameter)

auditReturnParameter = (mediaDescriptor / modemDescriptor /
                           muxDescriptor / eventsDescriptor /
                           signalsDescriptor / digitMapDescriptor /
                     observedEventsDescriptor / eventBufferDescriptor /
                           statisticsDescriptor / packagesDescriptor /
                            errorDescriptor / auditItem )

Shouldn't it be:

terminationAudit     = (auditReturnParameter *(COMMA
                        auditReturnParameter))/errorDescriptor   ????

Please,correct me if I'm wrong...

2)In "8.2.2 TransactionReply",  it is written:

   "If the end of a command cannot be reliably determined it will return
   442 Syntax Error in Command as the reply to the last action it can
   parse."

    I understand from this text that in case that there were
    a few commands in the commandRequestList & only one of
them is erroneous, the Transaction Reply will include this context
twice:
  The first one with reply to the correct commands & the second one with
   error descriptor instead of the erroneous command.

  Am I right?

Many thanks in advance,
--
Rakefet Prozan,
Team Manager, S/W Development
ATS SBU
Telrad Networks
ESN 828-3043   Email:rakefet.prozan@telrad.co.il


                                       """
                                     -(o o)-
+---------------------------------oOO--(_)--OOo--------------+

                               .oooO         Oooo.
-------------------------------(   )---------(   )------------
                                \ (           ) /
                                 \_)         (_/

Have fun !!!


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Dec 19 08:11:37 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12996
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 19 Dec 2000 08:11:37 -0500 (EST)
Received: from standards (47.234.32.16:4496) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC43F6@standards.nortelnetworks.com>; Tue, 19 Dec 2000 7:51:27 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 21184 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 19 Dec 2000 07:51:26 -0500
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC43F5@standards.nortelnetworks.com>; Tue, 19 Dec 2000 7:51:26
          -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id IAA29026; Tue, 19 Dec 2000 08:09:39 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com
          (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by
          mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA01160;
          Tue, 19 Dec 2000 08:09:40 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <Y7B3ZD74>; Tue, 19 Dec 2000 08:09:39 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID:  <4FBEA8857476D311A03300204840E1CF01A6EBD2@whq-msgusr-02.pit.comms.marconi.com>
Date:         Tue, 19 Dec 2000 08:09:39 -0500
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: DigMap Related Questions
X-To:         Kris Albert <kris_albert@lycos.com>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

>Can we assume that silence on the issue means the following consensus.
Never assume silence = consent!  Especially around meeting time.

>1. If a provisioned definition on a specific termination is overridden
>by an empty definition by MGC, while it is in (NULL/Non NULL) context,
>the digitmap becomes unavailable for the termination in that context
>even though the digitmap may have a provisioned value defined for the
>termination.
Yes
>The provisioned value becomes "visible" only when the termination
>"returns" to NULL context.
Yes if the override of the definition occurs when the termination
was in a context other than null.

>2. In case of ROOT termination, the provisioned value can NEVER be
>restored once MGC overrides it with a new value. Even an empty value
>being set by MGC for that digitmap name does not restore the provisioned
>value and the digitmap becomes undefined for ROOT until set to a new
>(non-empty) value  by MGC/provisioning.
Yes

Brian
ps - Rosen's Law of Provisioning - "Provisioning is evil"


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Dec 19 08:22:19 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13131
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 19 Dec 2000 08:22:19 -0500 (EST)
Received: from standards (47.234.32.16:4496) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC441F@standards.nortelnetworks.com>; Tue, 19 Dec 2000 8:02:24 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 21239 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 19 Dec 2000 08:02:23 -0500
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC441E@standards.nortelnetworks.com>; Tue, 19 Dec 2000 8:02:23
          -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id IAA29638; Tue, 19 Dec 2000 08:20:39 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com
          (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by
          mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA02916;
          Tue, 19 Dec 2000 08:20:41 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <Y7B3Z1JQ>; Tue, 19 Dec 2000 08:20: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:  <4FBEA8857476D311A03300204840E1CF01A6EBD3@whq-msgusr-02.pit.comms.marconi.com>
Date:         Tue, 19 Dec 2000 08:20:21 -0500
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: Error Descriptor Problems
X-To:         "Prozan, Rakefet [LOD:Telrad:SMTPPART]" 
              <rakefet.prozan@telrad.co.il>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

1. Your suggestion is probably correct.  Perhaps a Implementor's Guide item.

2. No, you would see something like:
Context=5555{Add=term1, Modify=term2, error=442....

Brian

-----Original Message-----
From: Prozan, Rakefet [LOD:Telrad:SMTPPART]
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Sent: 12/19/00 3:48 AM
Subject: Error Descriptor Problems

Hi all,

I have 2 questions regarding the errorDescriptor:

1) It is written in rfc3015.txt (page 61):

  " The TransactionReply includes
   the return values for the Commands that were executed successfully,
   and the Command and error descriptor for any Command that failed."

   So, I understand that if a command failed ,the reply will include the
 command token ,the TerminationID & the errorDescriptor.

  For instance, if there is an illegal parameter in one of the
  descriptors of an Add command, the reply  will look like:

  Add=55555{Error=455{Parameter illegal in this Descriptor}}.

  But on the other hand,the following definitions allow sending of
  other descriptors in the same command with the errorDescriptor:

ammsReply            = (AddToken / MoveToken / ModifyToken /
                           SubtractToken ) EQUAL TerminationID [ LBRKT
                           terminationAudit RBRKT ]

terminationAudit     = auditReturnParameter *(COMMA
                        auditReturnParameter)

auditReturnParameter = (mediaDescriptor / modemDescriptor /
                           muxDescriptor / eventsDescriptor /
                           signalsDescriptor / digitMapDescriptor /
                     observedEventsDescriptor / eventBufferDescriptor /
                           statisticsDescriptor / packagesDescriptor /
                            errorDescriptor / auditItem )

Shouldn't it be:

terminationAudit     = (auditReturnParameter *(COMMA
                        auditReturnParameter))/errorDescriptor   ????

Please,correct me if I'm wrong...

2)In "8.2.2 TransactionReply",  it is written:

   "If the end of a command cannot be reliably determined it will return
   442 Syntax Error in Command as the reply to the last action it can
   parse."

    I understand from this text that in case that there were
    a few commands in the commandRequestList & only one of
them is erroneous, the Transaction Reply will include this context
twice:
  The first one with reply to the correct commands & the second one with
   error descriptor instead of the erroneous command.

  Am I right?

Many thanks in advance,
--
Rakefet Prozan,
Team Manager, S/W Development
ATS SBU
Telrad Networks
ESN 828-3043   Email:rakefet.prozan@telrad.co.il


                                       """
                                     -(o o)-
+---------------------------------oOO--(_)--OOo--------------+

                               .oooO         Oooo.
-------------------------------(   )---------(   )------------
                                \ (           ) /
                                 \_)         (_/

Have fun !!!


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Dec 19 14:52:53 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23134
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 19 Dec 2000 14:52:53 -0500 (EST)
Received: from standards (47.234.32.16:1111) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC45E0@standards.nortelnetworks.com>; Tue, 19 Dec 2000 14:32:46 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 21842 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 19 Dec 2000 14:32:45 -0500
Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC45DF@standards.nortelnetworks.com>; Tue, 19 Dec 2000
          14:32:45 -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 OAA21423
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 19 Dec 2000 14:51:04
          -0500 (EST)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by
          hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id OAA21419
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 19 Dec 2000 14:51:04
          -0500 (EST)
Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA18031; Tue, 19 Dec
          2000 14:51:00 -0500
Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id
          OAA18028; Tue, 19 Dec 2000 14:50:59 -0500
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3A3FBBD1.231C45A5@lucent.com>
Date:         Tue, 19 Dec 2000 14:49:37 -0500
Reply-To: Troy Cauble <troy@bell-labs.com>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Troy Cauble <troy@LUCENT.COM>
Subject:      ASN.1 encoding of package elements
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Brian, Christian, Tom, et. al.,

Can we please nail down how to ASN.1 encode/decode
package elements?

Double-wrapping has been discussed in the group a
couple of times, but I haven't seen it in the
Implementor's Guide or otherwise "approved".

Double-wrapping refers to BER encoding an object,
taking the resulting octets, and encoding them
as OCTET STRING.

In the H.248 case, it would mean BER encoding a package
element based on it's type as defined in the package.
Then encoding the BER output as the OCTET STRING in
the H.248 protocol.

If we agree on that much, we still need to specify the
proper BER encoding type for each package element type.
I propose the following:


  Package Type
(12.1.2 or 12.2)                     ASN.1 BER
===================                  =========
String (UTF-8)                       IA5String
Integer (4 octet)                    INTEGER
Double (8 octet signed int)          INTEGER (***)
Character: (UTF-8, *)                IA5String
Enumeration:                         ENUM
Boolean:                             BOOLEAN
Unsigned Integer: (**)               INTEGER (***)


*    Can be more than one byte.
**   Unsigned integer is referenced in Annex C.
***  My understanding of ASN.1 is that INTEGER does not
     imply 4 bytes.  It'll use whatever's needed.

-troy


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Dec 19 17:50:57 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26787
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 19 Dec 2000 17:50:56 -0500 (EST)
Received: from standards (47.234.32.16:4342) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC4781@standards.nortelnetworks.com>; Tue, 19 Dec 2000 17:31:11 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22416 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 19 Dec 2000 17:31:11 -0500
Received: from mail.winsocket.com (sdsl-216-46-65-3.dsl.nyc.megapath.net) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC477E@standards.nortelnetworks.com>; Tue, 19 Dec 2000
          17:21:11 -0500
Received: from localhost.localdomain [24.28.82.187] by mail.winsocket.com
          (SMTPD32-6.04) id A3A16290148; Tue, 19 Dec 2000 17:39:29 -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.50.4522.1200
Message-ID:  <NEBBIELHMLDIACLLJHCNCEKGCHAA.plong@packetizer.com>
Date:         Tue, 19 Dec 2000 16:39:28 -0600
Reply-To: plong@ipdialog.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Paul Long <plong@PACKETIZER.COM>
Subject:      Double quote not allowed
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

I noticed that the double-quote character (") is not allowed in COMMENT or
quotedString (escaped of course). Was this intentional?

Paul Long
ipDialog, Inc.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Dec 19 18:05:54 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27105
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 19 Dec 2000 18:05:53 -0500 (EST)
Received: from standards (47.234.32.16:4342) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC47A9@standards.nortelnetworks.com>; Tue, 19 Dec 2000 17:46:09 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 22465 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 19 Dec 2000 17:46:08 -0500
Received: from mail.winsocket.com (sdsl-216-46-65-3.dsl.nyc.megapath.net) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC47A2@standards.nortelnetworks.com>; Tue, 19 Dec 2000
          17:36:08 -0500
Received: from localhost.localdomain [24.28.82.187] by mail.winsocket.com
          (SMTPD32-6.04) id A71E6320148; Tue, 19 Dec 2000 17:54:22 -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.50.4522.1200
Message-ID:  <NEBBIELHMLDIACLLJHCNEEKHCHAA.plong@packetizer.com>
Date:         Tue, 19 Dec 2000 16:54:21 -0600
Reply-To: plong@ipdialog.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Paul Long <plong@PACKETIZER.COM>
Subject:      Re: Double quote not allowed
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <NEBBIELHMLDIACLLJHCNCEKGCHAA.plong@packetizer.com>
Content-Transfer-Encoding: 7bit

Whoops! Okay, I see now that it is allowed in COMMENT, but it is still not
allowed in quotedString. Is it okay that a double quote can never appear in
an errorDescriptor or VALUE by way of quotedString?

Paul Long
ipDialog, Inc.

-----Original Message-----
From: Paul Long [mailto:plong@packetizer.com]
Sent: Tuesday, December 19, 2000 4:39 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Double quote not allowed


I noticed that the double-quote character (") is not allowed in COMMENT or
quotedString (escaped of course). Was this intentional?

Paul Long
ipDialog, Inc.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec 20 02:17:34 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA18390
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 20 Dec 2000 02:17:33 -0500 (EST)
Received: from standards (47.234.32.16:3437) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC49A1@standards.nortelnetworks.com>; Wed, 20 Dec 2000 1:57:39 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 23167 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Dec 2000 01:57:39 -0500
Received: from mail-in.audiocodes.com (AC-INT-LP.ser.netvision.net.il) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC49A0@standards.nortelnetworks.com>; Wed, 20 Dec 2000
          1:57:38 -0500
Received: by MAIL-IN with Internet Mail Service (5.5.2650.21) id <ZGTT8JB3>;
          Wed, 20 Dec 2000 09:14:49 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="windows-1255"
Message-ID:  <81C3E8FE6C0AD4119D49009027C3AAB25DAC7F@MAIL-IN>
Date:         Wed, 20 Dec 2000 09:14:48 +0200
Reply-To: Nurit Shenhar <nurit.shenhar@AUDIOCODES.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Nurit Shenhar <nurit.shenhar@AUDIOCODES.COM>
Subject:      MEGACO: DigitMap - some questions
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi list

No response, so I send my questions again.

Nurit

-----Original Message-----
From: Nurit Shenhar [mailto:nurit.shenhar@AUDIOCODES.COM]
Sent: Tuesday, December 05, 2000 2:59 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: MEGACO: DigitMap - some questions


Hi list

While implementing the digit map, I read again and again section 7.1.14.5
(DigitMap Procedures) and I have the following questions:

1. In which case do we send a completion event with no match? It seems that
the only possibilities are full match and partial match.

2. In small section 4 in this section, there is a discussion about the 'Z'
option. If I understand correctly, only those alternatives that has 'Z' and
matched the incoming event will stay as candidates, why then it says:
'If alternative event sequences not specifying a long duration event in the
given position remain in the candidate set after application of the
above rules, the observed event duration is treated as irrelevant in
assessing matches to them'.
?

3. And general question: Does the 'Z' means that when the event is finished
we check it's length, or it means that the alternative can be satisfies
during the event if it is long enough?

Best regards

Nurit Shenhar
AudioCodes Ltd.
Direct: +972-3-539-4155
Tel:     +972-3-539-4000
Fax:    +972-3-539-4040
email:  nurit.shenhar@audiocodes.com

web:    <http://www.audiocodes.com>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec 20 05:34:38 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA19792
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 20 Dec 2000 05:34:37 -0500 (EST)
Received: from standards (47.234.32.16:1425) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC4A71@standards.nortelnetworks.com>; Wed, 20 Dec 2000 5:14:43 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 23443 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Dec 2000 05:14:43 -0500
Received: from zmers013 (47.124.1.40:51080) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC4A70@standards.nortelnetworks.com>; Wed, 20 Dec 2000 5:14:43
          -0500
Received: from tlhuph12.elex.co.il (actually ertpg1e0.us.nortel.com) by
          zmers013; Wed, 20 Dec 2000 05:30:58 -0500
Received: from tmx100.elex.co.il (tmx100.elex.co.il [141.226.8.254]) by
          tlhuph12.elex.co.il (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id MAA02478
          for <MEGACO@standards.nortelnetworks.com>; Wed, 20 Dec 2000 12:31:06
          +0200 (IST)
Received: from tl100h0c.elex.co.il by tmx100.elex.co.il (8.8.8+Sun/SMI-SVR4) id
          MAA08049; Wed, 20 Dec 2000 12:31:05 +0200 (IST)
Received: from tmx100.elex.co.il (rakefet@localhost [127.0.0.1]) by
          tl100h0c.elex.co.il with ESMTP (8.8.6 (PHNE_14041)/8.7.3) id MAA11137
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 20 Dec 2000 12:31:04
          +0200 (IST)
X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.10.20 9000/712)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------9B3B423ACE836EA3D010D1FF"
Message-ID:  <3A408A67.9AE2DBFD@tmx100.elex.co.il>
Date:         Wed, 20 Dec 2000 12:31:03 +0200
Reply-To: "Prozan, Rakefet [LOD:Telrad:SMTPPART]"              <rakefet.prozan@telrad.co.il>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Prozan, Rakefet [LOD:Telrad:SMTPPART]"              <rakefet.prozan@telrad.co.il>
Organization: Telrad Ltd.
Subject:      [Fwd: Error Descriptor Problems]
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.
--------------9B3B423ACE836EA3D010D1FF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


--
Rakefet Prozan,
Team Manager, S/W Development
ATS SBU
Telrad Networks
ESN 828-3043   Email:rakefet.prozan@telrad.co.il


                                       """
                                     -(o o)-
+---------------------------------oOO--(_)--OOo--------------+

                               .oooO         Oooo.
-------------------------------(   )---------(   )------------
                                \ (           ) /
                                 \_)         (_/

Have fun !!!
--------------9B3B423ACE836EA3D010D1FF
Content-Type: message/rfc822
Content-Disposition: inline

X-Mozilla-Status2: 00000000
Message-ID: <3A408761.70723DC@tmx100.elex.co.il>
Date: Wed, 20 Dec 2000 12:18:09 +0200
From: Rakefet Prozan <rakefet@tmx100.elex.co.il>
Reply-To: rakefet.prozan@telrad.co.il
Organization: Telrad Ltd.
X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.10.20 9000/712)
X-Accept-Language: en
MIME-Version: 1.0
To: "Rosen, Brian" <Brian.Rosen@marconi.com>
Subject: Re: Error Descriptor Problems
References: <4FBEA8857476D311A03300204840E1CF01A6EBD3@whq-msgusr-02.pit.comms.marconi.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Rosen, Brian" wrote:
>
> 1. Your suggestion is probably correct.  Perhaps a Implementor's Guide item.
>
> 2. No, you would see something like:
> Context=5555{Add=term1, Modify=term2, error=442....
>
> Brian
>
> -----Original Message-----
> From: Prozan, Rakefet [LOD:Telrad:SMTPPART]
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Sent: 12/19/00 3:48 AM
> Subject: Error Descriptor Problems
>
> Hi all,
>
> I have 2 questions regarding the errorDescriptor:
>
> 1) It is written in rfc3015.txt (page 61):
>
>   " The TransactionReply includes
>    the return values for the Commands that were executed successfully,
>    and the Command and error descriptor for any Command that failed."
>
>    So, I understand that if a command failed ,the reply will include the
>  command token ,the TerminationID & the errorDescriptor.
>
>   For instance, if there is an illegal parameter in one of the
>   descriptors of an Add command, the reply  will look like:
>
>   Add=55555{Error=455{Parameter illegal in this Descriptor}}.
>
>   But on the other hand,the following definitions allow sending of
>   other descriptors in the same command with the errorDescriptor:
>
> ammsReply            = (AddToken / MoveToken / ModifyToken /
>                            SubtractToken ) EQUAL TerminationID [ LBRKT
>                            terminationAudit RBRKT ]
>
> terminationAudit     = auditReturnParameter *(COMMA
>                         auditReturnParameter)
>
> auditReturnParameter = (mediaDescriptor / modemDescriptor /
>                            muxDescriptor / eventsDescriptor /
>                            signalsDescriptor / digitMapDescriptor /
>                      observedEventsDescriptor / eventBufferDescriptor /
>                            statisticsDescriptor / packagesDescriptor /
>                             errorDescriptor / auditItem )
>
> Shouldn't it be:
>
> terminationAudit     = (auditReturnParameter *(COMMA
>                         auditReturnParameter))/errorDescriptor   ????
>
> Please,correct me if I'm wrong...
>
> 2)In "8.2.2 TransactionReply",  it is written:
>
>    "If the end of a command cannot be reliably determined it will return
>    442 Syntax Error in Command as the reply to the last action it can
>    parse."
>
>     I understand from this text that in case that there were
>     a few commands in the commandRequestList & only one of
> them is erroneous, the Transaction Reply will include this context
> twice:
>   The first one with reply to the correct commands & the second one with
>    error descriptor instead of the erroneous command.
>
>   Am I right?
>
> Many thanks in advance,
> --
> Rakefet Prozan,
> Team Manager, S/W Development
> ATS SBU
> Telrad Networks
> ESN 828-3043   Email:rakefet.prozan@telrad.co.il
>
>                                        """
>                                      -(o o)-
> +---------------------------------oOO--(_)--OOo--------------+
>
>                                .oooO         Oooo.
> -------------------------------(   )---------(   )------------
>                                 \ (           ) /
>                                  \_)         (_/
>
> Have fun !!!


Hi,

Regarding the second issue, the example you gave -

Context=5555{Add=term1, Modify=term2, error=442....

  can not be correct,
because the definition of the actionReply is:

actionReply          = CtxToken EQUAL ContextID LBRKT
                          ( errorDescriptor / commandReply ) RBRKT

Therefore, either the action Reply consists of commandReply or
errorDescriptor, but not both...

In some cases, like when the end of a command can not be determined,
the actionReply might look like:

Context=5555{Add=term1, Modify=term2, Add=term3{error=442}}

But, what if the problem is "Unknown Command" (443)?

Do we have to disregard all the other correct commands in the context
& send in the reply only the errorDescriptor?

Regards,
--
Rakefet Prozan,
Team Manager, S/W Development
ATS SBU
Telrad Networks
ESN 828-3043   Email:rakefet.prozan@telrad.co.il


                                       """
                                     -(o o)-
+---------------------------------oOO--(_)--OOo--------------+

                               .oooO         Oooo.
-------------------------------(   )---------(   )------------
                                \ (           ) /
                                 \_)         (_/

Have fun !!!

--------------9B3B423ACE836EA3D010D1FF--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec 20 08:20:05 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22803
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 20 Dec 2000 08:20:04 -0500 (EST)
Received: from standards (47.234.32.16:1760) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC4B31@standards.nortelnetworks.com>; Wed, 20 Dec 2000 8:00:04 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 23689 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Dec 2000 08:00:04 -0500
Received: from zmers013 (47.124.1.40:39167) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC4B30@standards.nortelnetworks.com>; Wed, 20 Dec 2000 8:00:04
          -0500
Received: from tlhuph12.elex.co.il (actually ertpg1e0.us.nortel.com) by
          zmers013; Wed, 20 Dec 2000 08:18:00 -0500
Received: from tmx100.elex.co.il (tmx100.elex.co.il [141.226.8.254]) by
          tlhuph12.elex.co.il (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id PAA10719
          for <MEGACO@standards.nortelnetworks.com>; Wed, 20 Dec 2000 15:18:06
          +0200 (IST)
Received: from tl100h0c.elex.co.il by tmx100.elex.co.il (8.8.8+Sun/SMI-SVR4) id
          PAA17356; Wed, 20 Dec 2000 15:18:05 +0200 (IST)
Received: from tmx100.elex.co.il (rakefet@localhost [127.0.0.1]) by
          tl100h0c.elex.co.il with ESMTP (8.8.6 (PHNE_14041)/8.7.3) id PAA11551
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 20 Dec 2000 15:18:04
          +0200 (IST)
X-Mailer: Mozilla 4.7 [en] (X11; I; HP-UX B.10.20 9000/712)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3A40B18B.554CC607@tmx100.elex.co.il>
Date:         Wed, 20 Dec 2000 15:18:03 +0200
Reply-To: "Prozan, Rakefet [LOD:Telrad:SMTPPART]"              <rakefet.prozan@telrad.co.il>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Prozan, Rakefet [LOD:Telrad:SMTPPART]"              <rakefet.prozan@telrad.co.il>
Organization: Telrad Ltd.
Subject:      Error Code for "Context Property appears twice this context"
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi,

Context properties are defined as "at most once":

; at-most-once
   contextProperty  = (topologyDescriptor / priority / EmergencyToken)

Context audit Properties are also defined as "at most once":

 ; at-most-once
   contextAuditProperties = ( TopologyToken / EmergencyToken /
                              PriorityToken )

I didn't find a suitable Error Code for the case of a
Context Property that appears twice.
There is an error code no:456: "Parameter or Property appears twice
in this Descriptor", but it refers to a property within a descriptor
within a  command & not to a property within a context.

Please, correct me if I'm wrong..

Many thanks in advance,
--
Rakefet Prozan,
Team Manager, S/W Development
ATS SBU
Telrad Networks
ESN 828-3043   Email:rakefet.prozan@telrad.co.il


                                       """
                                     -(o o)-
+---------------------------------oOO--(_)--OOo--------------+

                               .oooO         Oooo.
-------------------------------(   )---------(   )------------
                                \ (           ) /
                                 \_)         (_/

Have fun !!!


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec 20 09:10:19 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24972
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 20 Dec 2000 09:10:19 -0500 (EST)
Received: from standards (47.234.32.16:1760) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC4BCC@standards.nortelnetworks.com>; Wed, 20 Dec 2000 8:50:17 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 23882 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Dec 2000 08:50:17 -0500
Received: from auemail2.firewall.lucent.com (auemail2.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC4BCB@standards.nortelnetworks.com>; Wed, 20 Dec 2000
          8:50:17 -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 JAA23673
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 20 Dec 2000 09:08:38
          -0500 (EST)
Received: from nj7460exch002h.wins.lucent.com (h135-17-42-35.lucent.com
          [135.17.42.35]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3)
          with ESMTP id JAA23657 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>;
          Wed, 20 Dec 2000 09:08:37 -0500 (EST)
Received: by nj7460exch002h.ho.lucent.com with Internet Mail Service
          (5.5.2650.21) id <ZALCZZ7M>; Wed, 20 Dec 2000 09:08:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="windows-1255"
Message-ID:  <F38185D061EBD21185F10008C7F926CE04A61261@nj7460exch007u.ho.lucent.com>
Date:         Wed, 20 Dec 2000 09:08:31 -0500
Reply-To: "Griffeth, Nancy D (Nancy)" <nancyg@LUCENT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Griffeth, Nancy D (Nancy)" <nancyg@LUCENT.COM>
Subject:      Re: MEGACO: DigitMap - some questions
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Nurit,

I've spent some time going over the digit map processing, so I'll give you
my best shot on part 1 of
your question:

Actually, there are 3 possibilities:
UM - unambiguous match
PM - partial match
FM - full match

UM (unambiguous match) means that the gateway has received a dial string
that matches one of the dial
strings specified by the digit map.  Furthermore, getting more digits will
not give you a different match.

FM (full match) means that the gateway has received a dial string that
matches one of the dial strings specified
in the digit map; more digits might match a different string, but either a
timeout or an unmatchable digit has
been received.

PM (partial match) means not matched, in my view - in other words, some
prefix of a dial string has been
matched, but no full string, and either a timeout or a unmatchable digit has
been received.

As far as I can tell, the unmatchable digits are thrown away, because the
digit map completion event is
disabled with the result that there will be no more digit map processing.

Nancy Griffeth


-----Original Message-----
From: Nurit Shenhar [mailto:nurit.shenhar@AUDIOCODES.COM]
Sent: Wednesday, December 20, 2000 1:15 AM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: MEGACO: DigitMap - some questions


Hi list

No response, so I send my questions again.

Nurit

-----Original Message-----
From: Nurit Shenhar [mailto:nurit.shenhar@AUDIOCODES.COM]
Sent: Tuesday, December 05, 2000 2:59 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: MEGACO: DigitMap - some questions


Hi list

While implementing the digit map, I read again and again section 7.1.14.5
(DigitMap Procedures) and I have the following questions:

1. In which case do we send a completion event with no match? It seems that
the only possibilities are full match and partial match.

2. In small section 4 in this section, there is a discussion about the 'Z'
option. If I understand correctly, only those alternatives that has 'Z' and
matched the incoming event will stay as candidates, why then it says:
'If alternative event sequences not specifying a long duration event in the
given position remain in the candidate set after application of the
above rules, the observed event duration is treated as irrelevant in
assessing matches to them'.
?

3. And general question: Does the 'Z' means that when the event is finished
we check it's length, or it means that the alternative can be satisfies
during the event if it is long enough?

Best regards

Nurit Shenhar
AudioCodes Ltd.
Direct: +972-3-539-4155
Tel:     +972-3-539-4000
Fax:    +972-3-539-4040
email:  nurit.shenhar@audiocodes.com

web:    <http://www.audiocodes.com>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec 20 09:42:32 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26396
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 20 Dec 2000 09:42:32 -0500 (EST)
Received: from standards (47.234.32.16:1760) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC4C20@standards.nortelnetworks.com>; Wed, 20 Dec 2000 9:22:33 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 23989 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Dec 2000 09:22:33 -0500
Received: from smtp4.cluster.oleane.net by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBC4C1F@standards.nortelnetworks.com>; Wed, 20 Dec 2000 9:22:32
          -0500
Received: from oleane (dyn-1-1-020.Vin.dialup.oleane.fr [195.25.4.20]) by
          smtp4.cluster.oleane.net with SMTP id eBKEf9V08177 for
          <megaco@standards.nortelnetworks.com>; Wed, 20 Dec 2000 15:41:10
          +0100 (CET)
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_0050_01C06A9B.81A7B220"
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:  <005301c06a93$20606960$8001a8c0@oleane.com>
Date:         Wed, 20 Dec 2000 15:42:49 +0100
Reply-To: Peter Lewis <peter.lewis@UPPERSIDE.FR>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Peter Lewis <peter.lewis@UPPERSIDE.FR>
Subject:      International SIP 2001
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_0050_01C06A9B.81A7B220
Content-Type: text/plain;
        charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable



The International SIP 2001 programme is online. The event will take =
place next February 20 to 23, in Paris. The most eminent specialists in =
this technology will be on hand to discuss one of the most significant =
advances made in the domain of telephony over IP: the break through of =
the SIP protocol.=20
Visit the first SIP exhibition.
Please get more details at:
http://www.upperside.fr/baintersip.htm

------=_NextPart_000_0050_01C06A9B.81A7B220
Content-Type: text/html;
        charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>
<DIV><BR></DIV>
<DIV>
<DIV><FONT color=3D#000000 size=3D2>
<DIV><FONT color=3D#000000 size=3D2>The <STRONG>International SIP 2001=20
</STRONG>programme is online. The event will take place next February 20 =
to 23,=20
in Paris. The most eminent specialists in this technology will be on =
hand to=20
discuss one of the most significant advances made in the domain of =
telephony=20
over IP: the break through of the SIP protocol. </FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>Visit the first <STRONG>SIP=20
exhibition</STRONG>.</DIV>
<DIV><FONT color=3D#000000 size=3D2>Please get more details =
at:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT><FONT size=3D2><A=20
href=3D"http://www.upperside.fr/baintersip.htm">http://www.upperside.fr/b=
aintersip.htm</A></FONT></DIV></FONT></DIV></DIV></FONT></DIV></BODY></HT=
ML>

------=_NextPart_000_0050_01C06A9B.81A7B220--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec 20 10:16:16 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28062
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 20 Dec 2000 10:16:16 -0500 (EST)
Received: from standards (47.234.32.16:3198) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC4C49@standards.nortelnetworks.com>; Wed, 20 Dec 2000 9:55:17 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 24044 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Dec 2000 09:55:17 -0500
Received: from hindon.hss.co.in (202.54.26.202:36373) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC4C48@standards.nortelnetworks.com>; Wed, 20 Dec 2000
          9:55:15 -0500
Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in
          (8.10.0/8.10.0) with SMTP id eBKFEVd13359 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 20 Dec 2000 20:44:52
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          652569BB.0052450F ; Wed, 20 Dec 2000 20:28:36 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <652569BB.005243BD.00@sandesh.hss.hns.com>
Date:         Wed, 20 Dec 2000 20:10:35 +0530
Reply-To: svkumar@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Shiv Kumar <svkumar@HSS.HNS.COM>
Subject:      ASN.1 - Name
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi

  In the ASN.1 notation in Annex A, the  Digit Map Name and Service Change
Profile Name
are of the Data Type 'Name',  which has is an OCTET STRING of 2 octets.

 Does this mean that we are supposed to send a 2 byte enumerated equivalent for
them
 or  is this an error and they should actually be of type  IA5String.

Regards
Shiv


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec 20 10:24:22 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28536
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 20 Dec 2000 10:24:21 -0500 (EST)
Received: from standards (47.234.32.16:3198) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC4C6B@standards.nortelnetworks.com>; Wed, 20 Dec 2000 10:04:30 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 24089 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Dec 2000 10:04:30 -0500
Received: from hindon.hss.co.in (202.54.26.202:36559) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC4C6A@standards.nortelnetworks.com>; Wed, 20 Dec 2000
          10:04:28 -0500
Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in
          (8.10.0/8.10.0) with SMTP id eBKFNOK13532 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 20 Dec 2000 20:53:45
          +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id
          652569BB.005351B7 ; Wed, 20 Dec 2000 20:40:04 +0530
X-Lotus-FromDomain: HSS
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID:  <652569BB.0053507E.00@sandesh.hss.hns.com>
Date:         Wed, 20 Dec 2000 20:51:52 +0530
Reply-To: svkumar@HSS.HNS.COM
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Shiv Kumar <svkumar@HSS.HNS.COM>
Subject:      ASN.1 - Values in Event and Signal Parameter
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi List,

The following structures descrbe the ASN.1 notation for Event and Signal
Parameters.

       EventParameter ::= SEQUENCE    {
         eventParameterName              Name,
         value                           Value    }


       SigParameter ::= SEQUENCE    {
         sigParameterName                Name,
         value                           Value    }

How  does one specify the Range/relation/Sub-list/Alternatives information  for
the Value list ?
I think we need one more field similar to the 'ExtraInfo' field in PropertyParm.

Regards
Shiv


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec 20 13:46:37 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09898
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 20 Dec 2000 13:46:37 -0500 (EST)
Received: from standards (47.234.32.16:3376) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC4E0F@standards.nortelnetworks.com>; Wed, 20 Dec 2000 13:26:30 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 24646 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Dec 2000 13:26:30 -0500
Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC4E0E@standards.nortelnetworks.com>; Wed, 20 Dec 2000
          13:26:30 -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 NAA16710
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 20 Dec 2000 13:44:52
          -0500 (EST)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by
          hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id NAA16706
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 20 Dec 2000 13:44:51
          -0500 (EST)
Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id NAA00499; Wed, 20 Dec
          2000 13:44:50 -0500
Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id
          NAA00492; Wed, 20 Dec 2000 13:44:48 -0500
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Original-CC: MEGACO@STANDARDS.NORTELNETWORKS.COM
References: <652569BB.005243BD.00@sandesh.hss.hns.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3A40FDCC.F3BCEBDD@lucent.com>
Date:         Wed, 20 Dec 2000 13:43:24 -0500
Reply-To: Troy Cauble <troy@bell-labs.com>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Troy Cauble <troy@LUCENT.COM>
Subject:      Re: ASN.1 - Name
X-To:         svkumar@HSS.HNS.COM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Shiv Kumar wrote:
>
> Hi
>
>   In the ASN.1 notation in Annex A, the  Digit Map Name and Service Change
> Profile Name
> are of the Data Type 'Name',  which has is an OCTET STRING of 2 octets.
>
>  Does this mean that we are supposed to send a 2 byte enumerated equivalent for
> them
>  or  is this an error and they should actually be of type  IA5String.
>
> Regards
> Shiv

The 2 byte numeric equivalent.

-troy


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec 20 21:45:08 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23402
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 20 Dec 2000 21:45:03 -0500 (EST)
Received: from standards (47.234.32.16:1166) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC5080@standards.nortelnetworks.com>; Wed, 20 Dec 2000 21:25:01 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 25509 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 20 Dec 2000 21:25:01 -0500
Received: from mailgate.sbell.com.cn by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBC507F@standards.nortelnetworks.com>; Wed, 20 Dec 2000 21:25:00
          -0500
Received: from bellnet-mail4.sbell.com.cn (bellnet-mail4.sbell.com.cn
          [172.16.207.166]) by mailgate.sbell.com.cn (8.9.2/8.9.2) with ESMTP
          id KAA02176; Thu, 21 Dec 2000 10:35:19 +0800 (CST)
Received: by bellnet-mail4.sbell.com.cn with Internet Mail Service
          (5.5.2650.21) id <YX2QC0Q1>; Thu, 21 Dec 2000 10:42:16 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Message-ID:  <DC953147EF799A458094314B62C726187FD2E6@bellnet-mail1.sbell.com.cn>
Date:         Thu, 21 Dec 2000 10:31:35 +0800
Reply-To: SRD Tian YaMin <SRDTYM@SBELL.COM.CN>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: SRD Tian YaMin <SRDTYM@SBELL.COM.CN>
Subject:      Fw: Binary encoding in SDP
X-cc:         "Brian.Rosen@MARCONI.COM" <Brian.Rosen@MARCONI.COM>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hello Sir:
   Below is the question also puzzles me, but nobody answer it.
Now I use PropertyParm.name  = 00006001 , PropertyParm.value = RTPAddrValue,
and
PropertyParm.name  = 00006003 , PropertyParm.value = RTPPortValue
to stand for the RTP address in Local/RemoteDescriptor, and SDP Equivalents
are not used.
I need somebody to justify my thoughts. Can u help me?
Thanks

Tian Yamin



>Hi Sir :
>
>We have a question about binary encoding in SDP, can you help us?
>In Annex A, SDP binary encoding use :
>ProperParm :: = SEQUENCE
>{
>    name    pKgdName,
>    value    SEQUENCE OF OCTET STRING,
>    ....
>}
>
>if I want to encode the following SDP:
>v=0
>c=IN IP4 $
>
>1. What I need to put in PropertyParm.name ?
>v=0                =====> 0000B001
>c=IN IP4 $     =====>  0000B008 or 00006001
>
>2. What I need to put in PropertyParm.value?
>Is ASCII of all the string "v=0" and "c=IN IP4 $" or someing else ?
>
>Best regards
>Yieng-Chang Liao


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec 21 09:18:18 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20310
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 21 Dec 2000 09:18:18 -0500 (EST)
Received: from standards (47.234.32.16:2351) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC52E5@standards.nortelnetworks.com>; Thu, 21 Dec 2000 8:58:09 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 26324 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Dec 2000 08:58:09 -0500
Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC52E4@standards.nortelnetworks.com>; Thu, 21 Dec 2000 8:58:09
          -0500
Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com
          [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with
          ESMTP id JAA19468; Thu, 21 Dec 2000 09:16:31 -0500 (EST)
Received: from whq-msgrtr-01.pit.comms.marconi.com
          (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by
          mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA20862;
          Thu, 21 Dec 2000 09:16:24 -0500 (EST)
Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service
          (5.5.2650.21) id <Y7B373J3>; Thu, 21 Dec 2000 09:16: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:  <4FBEA8857476D311A03300204840E1CF01A6EC05@whq-msgusr-02.pit.comms.marconi.com>
Date:         Thu, 21 Dec 2000 09:16:21 -0500
Reply-To: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
Subject:      Re: Binary encoding in SDP
X-To:         SRD Tian YaMin <SRDTYM@sbell.com.cn>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Your choice of words is confusing, but your choice of parameters
is correct.

When using binary encoding of the Megaco protocol, one does not
use SDP at all. One uses Annex C tags.  For an RTP flow,
RTPAddrValue and RTPPortValue are correct.

Brian

> -----Original Message-----
> From: SRD Tian YaMin [mailto:SRDTYM@sbell.com.cn]
> Sent: Wednesday, December 20, 2000 9:32 PM
> To: 'MEGACO@STANDARDS.NORTELNETWORKS.COM'
> Cc: 'Brian.Rosen@MARCONI.COM'
> Subject: Fw: Binary encoding in SDP
>
>
> Hello Sir:
>    Below is the question also puzzles me, but nobody answer it.
> Now I use PropertyParm.name  = 00006001 , PropertyParm.value
> = RTPAddrValue,
> and
> PropertyParm.name  = 00006003 , PropertyParm.value = RTPPortValue
> to stand for the RTP address in Local/RemoteDescriptor, and
> SDP Equivalents
> are not used.
> I need somebody to justify my thoughts. Can u help me?
> Thanks
>
> Tian Yamin
>
>
>
> >Hi Sir :
> >
> >We have a question about binary encoding in SDP, can you help us?
> >In Annex A, SDP binary encoding use :
> >ProperParm :: = SEQUENCE
> >{
> >    name    pKgdName,
> >    value    SEQUENCE OF OCTET STRING,
> >    ....
> >}
> >
> >if I want to encode the following SDP:
> >v=0
> >c=IN IP4 $
> >
> >1. What I need to put in PropertyParm.name ?
> >v=0                =====> 0000B001
> >c=IN IP4 $     =====>  0000B008 or 00006001
> >
> >2. What I need to put in PropertyParm.value?
> >Is ASCII of all the string "v=0" and "c=IN IP4 $" or someing else ?
> >
> >Best regards
> >Yieng-Chang Liao
>


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec 21 10:30:13 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22113
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 21 Dec 2000 10:30:13 -0500 (EST)
Received: from standards (47.234.32.16:3100) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC539C@standards.nortelnetworks.com>; Thu, 21 Dec 2000 10:10:04 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 26571 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Dec 2000 10:10:04 -0500
Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC539B@standards.nortelnetworks.com>; Thu, 21 Dec 2000
          10:10:03 -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 KAA20132
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 21 Dec 2000 10:28:23
          -0500 (EST)
Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com
          [135.17.42.36]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3)
          with ESMTP id KAA20120 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>;
          Thu, 21 Dec 2000 10:28:23 -0500 (EST)
Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service
          (5.5.2650.21) id <ZFBLD50F>; Thu, 21 Dec 2000 10:28: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:  <F38185D061EBD21185F10008C7F926CE04A6127F@nj7460exch007u.ho.lucent.com>
Date:         Thu, 21 Dec 2000 10:28:17 -0500
Reply-To: "Griffeth, Nancy D (Nancy)" <nancyg@LUCENT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Griffeth, Nancy D (Nancy)" <nancyg@LUCENT.COM>
Subject:      Re: Binary encoding in SDP
X-To:         SRD Tian YaMin <SRDTYM@SBELL.COM.CN>
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Tian,

Normally, you won't encode SDP.

Instead you use SDP for text encoding and Annex C for binary encoding.

Nancy Griffeth

-----Original Message-----
From: SRD Tian YaMin [mailto:SRDTYM@SBELL.COM.CN]
Sent: Wednesday, December 20, 2000 9:32 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Fw: Binary encoding in SDP


Hello Sir:
   Below is the question also puzzles me, but nobody answer it.
Now I use PropertyParm.name  = 00006001 , PropertyParm.value = RTPAddrValue,
and
PropertyParm.name  = 00006003 , PropertyParm.value = RTPPortValue
to stand for the RTP address in Local/RemoteDescriptor, and SDP Equivalents
are not used.
I need somebody to justify my thoughts. Can u help me?
Thanks

Tian Yamin



>Hi Sir :
>
>We have a question about binary encoding in SDP, can you help us?
>In Annex A, SDP binary encoding use :
>ProperParm :: = SEQUENCE
>{
>    name    pKgdName,
>    value    SEQUENCE OF OCTET STRING,
>    ....
>}
>
>if I want to encode the following SDP:
>v=0
>c=IN IP4 $
>
>1. What I need to put in PropertyParm.name ?
>v=0                =====> 0000B001
>c=IN IP4 $     =====>  0000B008 or 00006001
>
>2. What I need to put in PropertyParm.value?
>Is ASCII of all the string "v=0" and "c=IN IP4 $" or someing else ?
>
>Best regards
>Yieng-Chang Liao


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec 21 13:22:20 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26531
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 21 Dec 2000 13:22:19 -0500 (EST)
Received: from standards (47.234.32.16:4614) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC565D@standards.nortelnetworks.com>; Thu, 21 Dec 2000 13:02:13 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 27525 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Dec 2000 13:02:12 -0500
Received: from rtp-msg-core-1.cisco.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBC5658@standards.nortelnetworks.com>; Thu, 21 Dec 2000 12:52:12
          -0500
Received: from dingdong.cisco.com (dingdong.cisco.com [161.44.3.16]) by
          rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA28314 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 21 Dec 2000 13:10:32
          -0500 (EST)
Received: from cisco.com (dhcp-64-102-95-140.cisco.com [64.102.95.140]) by
          dingdong.cisco.com (Mirapoint) with ESMTP id ADR03256 (AUTH dlinton);
          Thu, 21 Dec 2000 13:10:35 -0500 (EST)
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3A424722.7C03446@cisco.com>
Date:         Thu, 21 Dec 2000 13:08:34 -0500
Reply-To: Dan Linton <dlinton@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Dan Linton <dlinton@CISCO.COM>
Organization: Cisco Systems, Packet Telephony Division - XGCP Session Protocols
Subject:      Use of CHOOSE in the Remote descriptor
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Is CHOOSE allowed in the Remote descriptor sent to the MG?
RFC 3015 page 28 indicates that it is allowed. However, it doesn't
seem to make any sense in the Remote descriptor. In particular, I'm
referring to underspecified parameters that contain $ (e.g. IP address
and port). I am not referring to overspecified parameters (e.g. multiple

session descriptions) where an MG must select between the groups
or values.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec 21 13:29:17 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26707
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 21 Dec 2000 13:29:17 -0500 (EST)
Received: from standards (47.234.32.16:4614) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC5692@standards.nortelnetworks.com>; Thu, 21 Dec 2000 13:09:16 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 27526 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Dec 2000 13:09:16 -0500
Received: from rtp-msg-core-1.cisco.com by standards.nortelnetworks.com (LSMTP
          for Windows NT v1.1b) with SMTP id
          <0.FFBC5659@standards.nortelnetworks.com>; Thu, 21 Dec 2000 12:59:16
          -0500
Received: from dingdong.cisco.com (dingdong.cisco.com [161.44.3.16]) by
          rtp-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA28595 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Thu, 21 Dec 2000 13:17:36
          -0500 (EST)
Received: from cisco.com (dhcp-64-102-95-140.cisco.com [64.102.95.140]) by
          dingdong.cisco.com (Mirapoint) with ESMTP id ADR03365 (AUTH dlinton);
          Thu, 21 Dec 2000 13:17:40 -0500 (EST)
X-Mailer: Mozilla 4.5 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3A4248CA.5E5E486C@cisco.com>
Date:         Thu, 21 Dec 2000 13:15:39 -0500
Reply-To: Dan Linton <dlinton@CISCO.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Dan Linton <dlinton@CISCO.COM>
Organization: Cisco Systems, Packet Telephony Division - XGCP Session Protocols
Subject:      Symmetric versus asymmetric codec negotiation
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

The codec negotiation process for Megaco does not seem to preclude
the terminating MG from selecting asymmetric codecs even though
the originating MG may not support that functionality. Is this a
problem or did I misinterpret the specification?


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec 21 14:30:36 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28221
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 21 Dec 2000 14:30:35 -0500 (EST)
Received: from standards (47.234.32.16:4614) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC5768@standards.nortelnetworks.com>; Thu, 21 Dec 2000 14:10:27 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 27842 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 21 Dec 2000 14:10:26 -0500
Received: from zrchh190 (47.158.65.22:45423) by standards.nortelnetworks.com
          (LSMTP for Windows NT v1.1b) with SMTP id
          <0.FFBC573F@standards.nortelnetworks.com>; Thu, 21 Dec 2000 14:00:26
          -0500
Received: from zrtps06s.us.nortel.com by zrchh190; Thu, 21 Dec 2000 13:18:04
          -0600
Received: from zrtpd00y.us.nortel.com by zrtps06s.us.nortel.com; Thu, 21 Dec
          2000 14:15:57 -0500
Received: by zrtpd00y.us.nortel.com with Internet Mail Service (5.5.2652.35) id
          <ZG02BBKR>; Thu, 21 Dec 2000 14:15:45 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.35)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C06B82.68EEB9D0"
X-Orig: <crigano@americasm01.nt.com>
X-Orig: <crigano@nortelnetworks.com>
Message-ID:  <4FC0DB7A48D6D41193930000F81AC9BE642455@zrtpd00x.us.nortel.com>
Date:         Thu, 21 Dec 2000 14:15:41 -0500
Reply-To: "Rigano, Chris [NC1:3H14:EXCH]" <crigano@AMERICASM01.NT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Rigano, Chris [NC1:3H14:EXCH]" <crigano@AMERICASM01.NT.COM>
Subject:      H.248 Work Book, Negotiation and IAD contexts
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_01C06B82.68EEB9D0
Content-Type: text/plain;
        charset="iso-8859-1"

Hi everyone,

I would appreciate assistance with the following:

1) url for H.248 Work Book.

2) Where I can find the current approach to media/Codec negotiation(s).

3) Are there any proposed solutions for a GW requesting bearer path segment
from an IAD.

Thanks and have a happy holiday,

Chris



------_=_NextPart_001_01C06B82.68EEB9D0
Content-Type: text/html;
        charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
<TITLE>H.248 Work Book, Negotiation and IAD contexts</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2 FACE="Arial">Hi everyone,</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">I would appreciate assistance with the following:</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">1) url for H.248 Work Book.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">2) Where I can find the current approach to media/Codec negotiation(s).</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">3) Are there any proposed solutions for a GW requesting bearer path segment from an IAD.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Thanks and have a happy holiday,</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Chris</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C06B82.68EEB9D0--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec 22 19:13:57 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA16484
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 22 Dec 2000 19:13:57 -0500 (EST)
Received: from standards (47.234.32.16:4546) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC5E41@standards.nortelnetworks.com>; Fri, 22 Dec 2000 18:51:49 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 30149 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 22 Dec 2000 18:51:49 -0500
Received: from aomswin1.allenovery.com (mail1.allenovery.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC5E12@standards.nortelnetworks.com>; Fri, 22 Dec 2000
          18:41:48 -0500
Received: from mail.mindspring.com (unverified) by aomswin1.allenovery.com
          (Content Technologies SMTPRS 4.1.5) with SMTP id
          <Tc124ee7911150a5b7050f@aomswin1.allenovery.com> for
          <megaco@standards.nortelnetworks.com>; Sat, 23 Dec 2000 00:00:18 +0000
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID:  <762.770284.740975@mail.mindspring.com>
Date:         Fri, 22 Dec 2000 18:51:49 -0500
Reply-To: csdckpo@ICENET.ICENET.COM.AU
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: csdckpo@ICENET.ICENET.COM.AU
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

GET YOUR OWN 100 MEG WEBSITE FOR ONLY $11.95 PER MONTH TODAY!

STOP PAYING $19.95 or more TODAY for your web site, WHEN YOU CAN
GET ONE FOR ONLY $11.95 PER MONTH!

DO YOU ALREADY HAVE A WEBSITE? ALL YOU HAVE TO DO IS TRANSFER THE
DOMAIN TO OUR SERVERS AND UPLOAD YOUR DATA AND YOU ARE READY TO
GO! YOUR NEW WEB SPACE CAN BE CREATED INSTANTLY WITH JUST A
SIMPLE PHONE CALL TO  OUR OFFICE.

YOU CAN CHANGE THE DESIGN OF YOUR SITE AS MUCH AS YOU WANT with
no extra charge!  UNLIMITED TRAFFIC -- no extra charge!

FRONT PAGE EXTENSIONS are FULLY SUPPORTED.

A SET UP FEE OF $40.00 APPLIES for FIRST TIME CUSTOMERS.

ALL FEES PREPAID IN ADVANCE FOR THE YEAR PLUS A $40.00 SET UP
CHARGE.

FOR DETAILS CALL 1 888 248 0765  if you are outside the USA,
please fax 240 337 8325

Webhosting International


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Dec 26 02:06:22 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA17650
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 26 Dec 2000 02:06:21 -0500 (EST)
Received: from standards (47.234.32.16:3475) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC6527@standards.nortelnetworks.com>; Tue, 26 Dec 2000 1:45:51 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 32255 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 26 Dec 2000 01:45:51 -0500
Received: from pcs.csie.nctu.edu.tw. (pcs.csie.nctu.edu.tw) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC6526@standards.nortelnetworks.com>; Tue, 26 Dec 2000
          1:35:49 -0500
Received: from PCS20 (pcs20.csie.nctu.edu.tw [140.113.214.123]) by
          pcs.csie.nctu.edu.tw. (8.9.3/8.9.3) with SMTP id OAA20414 for
          <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 26 Dec 2000 14:30:41
          +0800 (CST)
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_002F_01C06F47.883F8800"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
Message-ID:  <000401c06f05$2cf5cdc0$7bd6718c@csie.nctu.edu.tw>
Date:         Tue, 26 Dec 2000 14:24:18 +0800
Reply-To: Elgin Pang <ijpong@PCS.CSIE.NCTU.EDU.TW>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Elgin Pang <ijpong@PCS.CSIE.NCTU.EDU.TW>
Subject:      Unsubscribe
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

This is a multi-part message in MIME format.

------=_NextPart_000_002F_01C06F47.883F8800
Content-Type: text/plain;
        charset="big5"
Content-Transfer-Encoding: base64

DQo=

------=_NextPart_000_002F_01C06F47.883F8800
Content-Type: text/html;
        charset="big5"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWJp
ZzUiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0iTVNIVE1MIDUuMDAu
MjAxNC4yMTAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8Qk9E
WSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+DQo=

------=_NextPart_000_002F_01C06F47.883F8800--


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Tue Dec 26 08:22:39 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18951
	for <megaco-archive@LISTS.IETF.ORG>; Tue, 26 Dec 2000 08:22:38 -0500 (EST)
Received: from standards (47.234.32.16:4987) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC65F5@standards.nortelnetworks.com>; Tue, 26 Dec 2000 8:02:41 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 32546 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 26 Dec 2000 08:02:41 -0500
Received: from mailgate.sbell.com.cn by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBC65F4@standards.nortelnetworks.com>; Tue, 26 Dec 2000 8:02:40
          -0500
Received: from bellnet-mail4.sbell.com.cn (bellnet-mail4.sbell.com.cn
          [172.16.207.166]) by mailgate.sbell.com.cn (8.9.2/8.9.2) with ESMTP
          id VAA09757 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Tue, 26 Dec
          2000 21:13:14 +0800 (CST)
Received: by bellnet-mail4.sbell.com.cn with Internet Mail Service
          (5.5.2650.21) id <ZT3WLW4P>; Tue, 26 Dec 2000 21:20:41 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Message-ID:  <258CBD15739C864D883910D808AE270F5A609D@bellnet-mail1.sbell.com.cn>
Date:         Tue, 26 Dec 2000 21:20:38 +0800
Reply-To: SRD Tian YaMin <SRDTYM@SBELL.COM.CN>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: SRD Tian YaMin <SRDTYM@SBELL.COM.CN>
Subject:      how to encode Signals{}
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hello,
  Can anybody tell me how to encode Signals{}(empty signal) in binary
coding?
 Is  Signal.signalName needed ?

Thanks

Tian Yamin


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec 27 03:10:18 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA15267
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 27 Dec 2000 03:10:18 -0500 (EST)
Received: from standards (47.234.32.16:3450) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC68AC@standards.nortelnetworks.com>; Wed, 27 Dec 2000 2:49:52 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 33532 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 27 Dec 2000 02:49:52 -0500
Received: from mailgate.sbell.com.cn by standards.nortelnetworks.com (LSMTP for
          Windows NT v1.1b) with SMTP id
          <0.FFBC68AB@standards.nortelnetworks.com>; Wed, 27 Dec 2000 2:49:51
          -0500
Received: from bellnet-mail4.sbell.com.cn (bellnet-mail4.sbell.com.cn
          [172.16.207.166]) by mailgate.sbell.com.cn (8.9.2/8.9.2) with ESMTP
          id QAA25319 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 27 Dec
          2000 16:00:27 +0800 (CST)
Received: by bellnet-mail4.sbell.com.cn with Internet Mail Service
          (5.5.2650.21) id <ZT3WMAPW>; Wed, 27 Dec 2000 16:07:52 +0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Message-ID:  <258CBD15739C864D883910D808AE270F5A60A0@bellnet-mail1.sbell.com.cn>
Date:         Wed, 27 Dec 2000 16:07:51 +0800
Reply-To: SRD Tian YaMin <SRDTYM@SBELL.COM.CN>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: SRD Tian YaMin <SRDTYM@SBELL.COM.CN>
Subject:      Signals{}
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi, now I'm using bianry encoding to encode Signals{} in a ModifyRequest.
But I don't know how, now I have 4 ways, but I don't know which one is
correct or none is correct.
1.
                        ASN1T_SignalName SignalName;
                        SignalName.numocts = 4;
                        SignalName.data[0] = 0;                 // set
signalname to be 0
                        SignalName.data[1] = 0;
                        SignalName.data[2] = 0;
                        SignalName.data[3] = 0;

                        ASN1T_Signal    Signal;
                        memset(&Signal, 0, sizeof(Signal));
                        Signal.signalName = SignalName;

                        ASN1T_SignalRequest             SignalRequest[1];
                        SignalRequest[0].t = 1;
                        SignalRequest[0].u.signal = &Signal;

                        ASN1T_SignalsDescriptor SignalsDescriptor;
                        SignalsDescriptor.n = 1;
                        SignalsDescriptor.elem = SignalRequest;

                        ASN1T_AmmRequest ModifyRequest;
                        memset(&ModifyRequest, 0, sizeof(ModifyRequest));
                        ModifyRequest.m.signalsDescriptorPresent = 1;
                        ModifyRequest.signalsDescriptor = SignalsDescriptor;
                        ......


2.
                        ASN1T_Signal    Signal;
                        memset(&Signal, 0, sizeof(Signal));

                        ASN1T_SignalRequest             SignalRequest[1];
                        SignalRequest[0].t = 1;
                        SignalRequest[0].u.signal = &Signal;

                        ASN1T_SignalsDescriptor SignalsDescriptor;
                        SignalsDescriptor.n = 1;
                        SignalsDescriptor.elem = SignalRequest;

                        ASN1T_AmmRequest ModifyRequest;
                        memset(&ModifyRequest, 0, sizeof(ModifyRequest));
                        ModifyRequest.m.signalsDescriptorPresent = 1;
                        ModifyRequest.signalsDescriptor = SignalsDescriptor;
                        ......

3.
                        ASN1T_SignalRequest             SignalRequest[1];
                        SignalRequest[0].t = 1;
                        SignalRequest[0].u.signal = NULL;

                        ASN1T_SignalsDescriptor SignalsDescriptor;
                        SignalsDescriptor.n = 1;
                        SignalsDescriptor.elem = SignalRequest;

                        ASN1T_AmmRequest ModifyRequest;
                        memset(&ModifyRequest, 0, sizeof(ModifyRequest));
                        ModifyRequest.m.signalsDescriptorPresent = 1;
                        ModifyRequest.signalsDescriptor = SignalsDescriptor;
                        ......

4.
                        ASN1T_SignalsDescriptor SignalsDescriptor;
                        memset(&SignalsDescriptor, 0,
sizeof(SignalsDescriptor));

                        ASN1T_AmmRequest ModifyRequest;
                        memset(&ModifyRequest, 0, sizeof(ModifyRequest));
                        ModifyRequest.m.signalsDescriptorPresent = 1;
                        ModifyRequest.signalsDescriptor = SignalsDescriptor;


Thanks

Tian Yamin


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Wed Dec 27 09:38:18 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17552
	for <megaco-archive@LISTS.IETF.ORG>; Wed, 27 Dec 2000 09:38:17 -0500 (EST)
Received: from standards (47.234.32.16:2222) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC6960@standards.nortelnetworks.com>; Wed, 27 Dec 2000 9:18:05 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 33773 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 27 Dec 2000 09:18:05 -0500
Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC695F@standards.nortelnetworks.com>; Wed, 27 Dec 2000
          9:08:04 -0500
Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by
          ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id JAA18144
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Wed, 27 Dec 2000 09:26:46
          -0500 (EST)
Received: from nj7460exch001h.wins.lucent.com (h135-17-42-36.lucent.com
          [135.17.42.36]) by ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3)
          with ESMTP id JAA18138 for <MEGACO@STANDARDS.NORTELNETWORKS.COM>;
          Wed, 27 Dec 2000 09:26:46 -0500 (EST)
Received: by nj7460exch001h.ho.lucent.com with Internet Mail Service
          (5.5.2650.21) id <ZNDZTHLL>; Wed, 27 Dec 2000 09:26:46 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain
Message-ID:  <2E12619580C0D1118C6400805F9F4C9506BE31D0@nj7460exch001u.ho.lucent.com>
Date:         Wed, 27 Dec 2000 09:26:44 -0500
Reply-To: "Duraisamy, Kandaprabhu (Kandaprabhu)** CTR **" <kd19@LUCENT.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: "Duraisamy, Kandaprabhu (Kandaprabhu)** CTR **" <kd19@LUCENT.COM>
Subject:      NonStandard data
To: MEGACO@STANDARDS.NORTELNETWORKS.COM

Hi all,

Can anybody help me out with the following:
How is the nonstandarddata encoded in ABNF?All i can find is  'extension
paramter' and 'extension'.Is there anything for the H221NonStandard &
NonStandardIdentifer?

Thanks
Kandaprabhu


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Thu Dec 28 02:03:35 2000
Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA12594
	for <megaco-archive@LISTS.IETF.ORG>; Thu, 28 Dec 2000 02:03:34 -0500 (EST)
Received: from standards (47.234.32.16:1287) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC6A67@standards.nortelnetworks.com>; Thu, 28 Dec 2000 1:38:26 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 34047 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 28 Dec 2000 01:38:26 -0500
Received: from acacia.bora.net (164.124.107.29:58527) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC6A43@standards.nortelnetworks.com>; Thu, 28 Dec 2000
          1:28:25 -0500
Received: from shlee ([211.170.54.90]) by acacia.bora.net (NoSpam/NoSpam) with
          SMTP id PAA16797 for <megaco@standards.nortelnetworks.com>; Thu, 28
          Dec 2000 15:47:07 +0900 (KST)
MIME-Version: 1.0
Content-Type: text/plain; charset="ks_c_5601-1987"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Message-ID:  <NEBBLHJCILCFFGEIJPEIIEBOCAAA.shlee01@xener.com>
Date:         Thu, 28 Dec 2000 15:42:18 +0900
Reply-To: =?ks_c_5601-1987?B?wMy8usjG?= <shlee01@XENER.COM>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: =?ks_c_5601-1987?B?wMy8usjG?= <shlee01@XENER.COM>
Subject:      listserv@standards.nortelnetworks.com
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id CAA12594

subscribe megaco SungHoon Lee


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec 29 18:28:40 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14125
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 29 Dec 2000 18:28:39 -0500 (EST)
Received: from standards (47.234.32.16:4762) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC6D5D@standards.nortelnetworks.com>; Fri, 29 Dec 2000 18:08:00 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 35031 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 29 Dec 2000 18:08:00 -0500
Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC6D5C@standards.nortelnetworks.com>; Fri, 29 Dec 2000
          18:07:59 -0500
Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by
          ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id SAA00513
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 29 Dec 2000 18:26:49
          -0500 (EST)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by
          ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id SAA00509
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 29 Dec 2000 18:26:48
          -0500 (EST)
Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id SAA21612; Fri, 29 Dec
          2000 18:26:47 -0500
Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id
          SAA21609; Fri, 29 Dec 2000 18:26:47 -0500
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3A4D1D60.D6916175@lucent.com>
Date:         Fri, 29 Dec 2000 18:25:20 -0500
Reply-To: Troy Cauble <troy@bell-labs.com>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Troy Cauble <troy@LUCENT.COM>
Subject:      ServiceChangeReason - Optional or not?
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Hi all,

ServiceChangeReason is optional in the ABNF encoding,
but not in the ASN.1 encoding.

All of the sample messages in Appendix A that
have ServiceChangeRequests omit it.

Is it optional or not?

-troy


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Fri Dec 29 18:45:40 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14229
	for <megaco-archive@LISTS.IETF.ORG>; Fri, 29 Dec 2000 18:45:40 -0500 (EST)
Received: from standards (47.234.32.16:4762) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC6D7E@standards.nortelnetworks.com>; Fri, 29 Dec 2000 18:25:26 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 35075 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 29 Dec 2000 18:25:26 -0500
Received: from ihemail1.firewall.lucent.com (ihemail1.lucent.com) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC6D7D@standards.nortelnetworks.com>; Fri, 29 Dec 2000
          18:25:25 -0500
Received: from ihemail1.firewall.lucent.com (localhost [127.0.0.1]) by
          ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id SAA06051
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 29 Dec 2000 18:44:15
          -0500 (EST)
Received: from wink.ho.lucent.com (h135-17-38-3.lucent.com [135.17.38.3]) by
          ihemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with SMTP id SAA06045
          for <MEGACO@STANDARDS.NORTELNETWORKS.COM>; Fri, 29 Dec 2000 18:44:15
          -0500 (EST)
Received: by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id SAA21746; Fri, 29 Dec
          2000 18:44:07 -0500
Received: from lucent.com by wink.ho.lucent.com (SMI-8.6/EMS-1.5 sol2) id
          SAA21743; Fri, 29 Dec 2000 18:44:01 -0500
X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
References: <3A4D1D60.D6916175@lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID:  <3A4D216A.BE2CC877@lucent.com>
Date:         Fri, 29 Dec 2000 18:42:34 -0500
Reply-To: Troy Cauble <troy@bell-labs.com>
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Troy Cauble <troy@LUCENT.COM>
Subject:      Re: ServiceChangeReason - Optional or not?
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Content-Transfer-Encoding: 7bit

Troy Cauble wrote:
>
> Hi all,
>
> ServiceChangeReason is optional in the ABNF encoding,
> but not in the ASN.1 encoding.
>
> All of the sample messages in Appendix A that
> have ServiceChangeRequests omit it.
>
> Is it optional or not?
>
> -troy

OK.  I guess an EMPTY serviceChangeReason Value
will correspond to a missing serviceChangeReason
in the ABNF.

So now the question is, how do I encode the following
specification as an OCTET STRING?

From 7.2.8:  [The ServiceChangeReason parameter] consists
of an alphanumeric token (IANA registered) and, optionally,
an explanitory string.

-try


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Dec 31 12:41:49 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08082
	for <megaco-archive@LISTS.IETF.ORG>; Sun, 31 Dec 2000 12:41:48 -0500 (EST)
Received: from standards (47.234.32.16:2980) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC6F95@standards.nortelnetworks.com>; 31 Dec 2000 12:21:14 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 35547 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 31 Dec 2000 12:21:13 -0500
Received: from mail.winsocket.com (sdsl-216-46-65-3.dsl.nyc.megapath.net) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC6F94@standards.nortelnetworks.com>; 31 Dec 2000 12:11:13
          -0500
Received: from localhost.localdomain [24.27.13.84] by mail.winsocket.com
          (SMTPD32-6.04) id AD1FD130154; Sun, 31 Dec 2000 12:30:07 -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.50.4522.1200
Message-ID:  <NEBBIELHMLDIACLLJHCNMENACHAA.plong@packetizer.com>
Date:         Sun, 31 Dec 2000 11:30:07 -0600
Reply-To: plong@ipdialog.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Paul Long <plong@PACKETIZER.COM>
Subject:      Zero not allowed
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <NEBBIELHMLDIACLLJHCNCEKGCHAA.plong@packetizer.com>
Content-Transfer-Encoding: 7bit

I noticed that an octet of zero is not allowed in the ABNF octetString. Was
this intentional?

Paul Long
ipDialog, Inc.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Dec 31 13:16:39 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08148
	for <megaco-archive@LISTS.IETF.ORG>; Sun, 31 Dec 2000 13:16:39 -0500 (EST)
Received: from standards (47.234.32.16:4402) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC6FAB@standards.nortelnetworks.com>; 31 Dec 2000 12:56:26 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 35574 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 31 Dec 2000 12:56:26 -0500
Received: from mail.winsocket.com (sdsl-216-46-65-3.dsl.nyc.megapath.net) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC6FAA@standards.nortelnetworks.com>; 31 Dec 2000 12:46:26
          -0500
Received: from localhost.localdomain [24.27.13.84] by mail.winsocket.com
          (SMTPD32-6.04) id A560FE70148; Sun, 31 Dec 2000 13:05:20 -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.50.4522.1200
Message-ID:  <NEBBIELHMLDIACLLJHCNEENBCHAA.plong@packetizer.com>
Date:         Sun, 31 Dec 2000 12:05:20 -0600
Reply-To: plong@ipdialog.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Paul Long <plong@PACKETIZER.COM>
Subject:      ABNF semantics
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <NEBBIELHMLDIACLLJHCNCEKGCHAA.plong@packetizer.com>
Content-Transfer-Encoding: 7bit

1. Do these two types of ABNF expressions always have the same semantics in
RFC3015? If so, can someone provide a rationale for the two different yet
equivalent expressions, e.g., are the LBRKTs sometimes needed to
disambiguate the grammar?
        LBRKT [ x ] LBRKT
        [ LBRKT x LBRKT ]

2. Are these two modem-descriptor examples equivalent? If so, why the two
syntaxes?
        md=v90
        md[v90]

3. I assume that the following alternativeValue expressions are all
equivalent to each other, correct?
        5
        [5]
        {5}
        [5:5]

4. The ABNF for secondEventParameter refers to "EmbedSig", which is not
defined. Therefore I assume it should be "embedSig", which is defined. A
simple typo.

Paul Long
ipDialog, Inc.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Dec 31 13:44:41 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08213
	for <megaco-archive@LISTS.IETF.ORG>; Sun, 31 Dec 2000 13:44:40 -0500 (EST)
Received: from standards (47.234.32.16:1775) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC6FC4@standards.nortelnetworks.com>; 31 Dec 2000 13:24:22 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 35604 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 31 Dec 2000 13:24:22 -0500
Received: from mail.winsocket.com (sdsl-216-46-65-3.dsl.nyc.megapath.net) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC6FC3@standards.nortelnetworks.com>; 31 Dec 2000 13:14:21
          -0500
Received: from localhost.localdomain [24.27.13.84] by mail.winsocket.com
          (SMTPD32-6.04) id ABEBC660136; Sun, 31 Dec 2000 13:33:15 -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.50.4522.1200
Message-ID:  <NEBBIELHMLDIACLLJHCNOENCCHAA.plong@packetizer.com>
Date:         Sun, 31 Dec 2000 12:33:15 -0600
Reply-To: plong@ipdialog.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Paul Long <plong@PACKETIZER.COM>
Subject:      "Once" is not enough :-)
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <NEBBIELHMLDIACLLJHCNEENBCHAA.plong@packetizer.com>
Content-Transfer-Encoding: 7bit

1. Regarding this idiom:
        y = x *x

        ; at-most-once
        x = a / b / c / d

Doesn't the comment refer to the use of x in y rather than x by itself? I
say this because x can only take on one of the alternative values at a time.

2. Are the these comments equivalent?
        ; at-most-once
        ; at-most-once per item
        ; at-most-once of each
        ; at-most-once each of x, y, z
        ; every x at most once

3. Does "exactly once x" mean that x is required and there cannot be
multiple occurrences of x?

Paul Long
ipDialog, Inc.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Dec 31 14:29:25 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08313
	for <megaco-archive@LISTS.IETF.ORG>; Sun, 31 Dec 2000 14:29:25 -0500 (EST)
Received: from standards (47.234.32.16:3239) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC6FE1@standards.nortelnetworks.com>; 31 Dec 2000 14:09:09 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 35636 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 31 Dec 2000 14:09:09 -0500
Received: from mail.winsocket.com (sdsl-216-46-65-3.dsl.nyc.megapath.net) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC6FDE@standards.nortelnetworks.com>; 31 Dec 2000 13:59:09
          -0500
Received: from localhost.localdomain [24.27.13.84] by mail.winsocket.com
          (SMTPD32-6.04) id A66BD740144; Sun, 31 Dec 2000 14:18:03 -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.50.4522.1200
Message-ID:  <NEBBIELHMLDIACLLJHCNKENDCHAA.plong@packetizer.com>
Date:         Sun, 31 Dec 2000 13:18:04 -0600
Reply-To: plong@ipdialog.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Paul Long <plong@PACKETIZER.COM>
Subject:      Command prefixes
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <NEBBIELHMLDIACLLJHCNOENCCHAA.plong@packetizer.com>
Content-Transfer-Encoding: 7bit

Does "O-" indicate an optional and "W-" a wildcarded command? I can't see
where they could mean anything else, but I also didn't see this defined
anywhere.

Paul Long
ipDialog, Inc.


From owner-megaco@STANDARDS.NORTELNETWORKS.COM  Sun Dec 31 17:44:39 2000
Received: from standards.nortelnetworks.com ([47.234.32.16])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA08857
	for <megaco-archive@LISTS.IETF.ORG>; Sun, 31 Dec 2000 17:44:37 -0500 (EST)
Received: from standards (47.234.32.16:2292) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBC7023@standards.nortelnetworks.com>; 31 Dec 2000 17:24:24 -0500
Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM
          (LISTSERV-TCP/IP release 1.8d) with spool id 35687 for
          MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 31 Dec 2000 17:24:24 -0500
Received: from mail.winsocket.com (sdsl-216-46-65-3.dsl.nyc.megapath.net) by
          standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP
          id <0.FFBC7022@standards.nortelnetworks.com>; 31 Dec 2000 17:14:23
          -0500
Received: from localhost.localdomain [24.27.13.84] by mail.winsocket.com
          (SMTPD32-6.04) id A42E2D0E014C; Sun, 31 Dec 2000 17:33:18 -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.50.4522.1200
Message-ID:  <NEBBIELHMLDIACLLJHCNGENECHAA.plong@packetizer.com>
Date:         Sun, 31 Dec 2000 16:33:18 -0600
Reply-To: plong@ipdialog.com
Sender: "Media Gateway Control (megaco)"              <MEGACO@STANDARDS.NORTELNETWORKS.COM>
From: Paul Long <plong@PACKETIZER.COM>
Subject:      Re: "Once" is not enough :-)
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
In-Reply-To:  <NEBBIELHMLDIACLLJHCNOENCCHAA.plong@packetizer.com>
Content-Transfer-Encoding: 7bit

Here a specific problem I'm having in this area.

Regarding this ABNF from RFC3015:
        terminationStateDescriptor = TerminationStateToken LBRKT
terminationStateParm *( COMMA terminationStateParm ) RBRKT
        ; at-most-once per item
        terminationStateParm =(propertyParm / serviceStates / eventBufferControl )

I assume the comment means that, for example, ServiceStates cannot be
specified as both Test and OutOfService and that Buffer cannot be both OFF
and LockStep. That's pretty straightforward; however, does it mean that only
one propertyParm can be specified or that only one propertyParm per
package/item identifier combination can be specified? IOW, I assume that
this is illegal
        PkgA/ItmA=3, PkgA/ItmA=6
but is the following also illegal?
        PkgA/ItmA=3, PkgA/ItmB=8
The comment isn't at all clear, IMO.

Paul Long
ipDialog, Inc.

-----Original Message-----
From: Media Gateway Control (megaco)
[mailto:MEGACO@STANDARDS.NORTELNETWORKS.COM]On Behalf Of Paul Long
Sent: Sunday, December 31, 2000 12:33 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: "Once" is not enough :-)


1. Regarding this idiom:
        y = x *x

        ; at-most-once
        x = a / b / c / d

Doesn't the comment refer to the use of x in y rather than x by itself? I
say this because x can only take on one of the alternative values at a time.

2. Are the these comments equivalent?
        ; at-most-once
        ; at-most-once per item
        ; at-most-once of each
        ; at-most-once each of x, y, z
        ; every x at most once

3. Does "exactly once x" mean that x is required and there cannot be
multiple occurrences of x?

Paul Long
ipDialog, Inc.