Subject: Re: Summary of Issues Raised On the List

From: John Segers <[email-masked]>
Date: Mon, 3 Apr 2000 15:56:01 +0200

Tom,

This is good work.  I compared your list of issues to the list I keep
myself (with input from others as well) and have some issues to add (see
attachment).

Cheers,

John

Tom-PT Taylor wrote:
>
> Attached please find a summary of the issues raised on the list.  The
> contents should be self-evident.  Please pay special attention to section 4:
> we MUST close off on these issues within the next week so we can end Last
> Call in timely fashion.
>  <<errata.txt>>
>
> Tom Taylor
> Advisor -- Emerging Carrier IP Standards
> E-mail: [email-masked] (internally, Tom-PT Taylor)
> Phone and FAX: +1 613 736 0961
>
> Media Gateway Control                                       P.T. Taylor
> Internet Draft                                          Nortel Networks
> Document: draft-ietf-megaco-errata-00.txt                    March 2000
> Category: Standards Track
>
>       Corrections To the Determined Megaco/H.248 Protocol Document
>
> Status of this Memo
>
>    This document is an Internet-Draft and is in full conformance with
>    all provisions of Section 10 of RFC2026 [1].
>
>    Internet-Drafts are working documents of the Internet Engineering
>    Task Force (IETF), its areas, and its working groups. Note that
>    other groups may also distribute working documents as Internet-
>    Drafts. Internet-Drafts are draft documents valid for a maximum of
>    six months and may be updated, replaced, or obsoleted by other
>    documents at any time. It is inappropriate to use Internet- Drafts
>    as reference material or to cite them other than as "work in
>    progress."
>    The list of current Internet-Drafts can be accessed at
>    http://www.ietf.org/ietf/1id-abstracts.txt
>    The list of Internet-Draft Shadow Directories can be accessed at
>    http://www.ietf.org/shadow.html.
>
> 1. Abstract
>
>    This document records the errors found in the draft Megaco/H.248
>    protocol document [2], along with the changes proposed in the text
>    of that document to resolve them. After joint IETF/ITU-T Study Group
>    16 approval of these corrections, they will be incorporated into the
>    final decided version of H.248 and the corresponding Megaco protocol
>    RFC.
>
> 2. Conventions used in this document
>
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
>    this document are to be interpreted as described in RFC-2119 [1].
>
> Taylor           Standards Track -- Expires Sep 2000                 1
>                        Megaco/H.248 Corrections             March 2000
>
> 3. Issues Not Found To Require Changes
>
>    This section lists a few of the issues raised on the Megaco list
>    which were found not to require a change in [2].  There were a
>    number of other such issues which may be recorded here as a matter
>    of record pending completion of IESG Last Call.  This section will
>    be deleted from the final document submitted into the ITU-T Study
>    Group 16 decision process.  All section numbers are from [2].
>
>    Section    Problem                         Resolution
>    7.1.9      Discarding of buffered events   No change.  Reasonable
>               when EventBufferControl is      case for making a
>               changed to OFF is               different decision from
>               inconsistent with provision     the one made in Geneva,
>               for notification of multiple    but not actually an
>               events at once in latter        error.
>               state.
>
>    7.1.11     Last bullet list and            Not an error or
>               preceding sentence simply       ambiguity, no action.
>               recapitulate definition of
>               KeepActive flag.
>    7.2.5,     Relationship between text and   Clarification, not
>    7.2.6      representation of wildcarded    ambiguity or error.
>               audit request is not clear.
>
> 4. Issues Identified But Not Yet Resolved
>
>    This section, as its title implies, contains issues which have been
>    identified in discussion on the list but for which a final
>    resolution has not been achieved.  All of these issues must be
>    resolved or moved to the previous section before Last Call can be
>    declared complete.  Hence this section will be deleted before this
>    document is submitted to the IESG for final approval.
>
>    Section                              Issue
>
>    6.2.2      Not clear what wildcard union responses look like.
>
>    7.1.1      Third para (discussing unspecified parameters): not clear
>               which parameters are mandatory.
>
> Taylor           Standards Track -- Expires Sep 2000                 2
>                        Megaco/H.248 Corrections             March 2000
>
>    7.1.9      Not clear whether events trigger side effects (e.g.
>               signal termination) at time of detection, at time of
>               processing (whether or not in active Events Descriptor)
>               or at time of notification.
>
>    7.1.14     Not clear whether non-matched events trigger side effects
>               at time of processing against digit map or when processed
>               against active Events Descriptor following digit map
>               completion event detection.
>
>    7.1.17     Not clear whether AuditValue of ObservedEventsDescriptor
>               reports events captured in current dial string of active
>               digit map.
>
>    7.3        There should be no error        Delete codes 404, 405,
>               responses to TransactionReply   461-467
>               or TransactionPending, lest
>               they create response loops.
>
>    8          Command execution should be     Not clear what "atomic"
>               specified as atomic.            means, particularly
>                                               where events and signals
>                                               are concerned.
>
>    12.2,      Text indicates that statistics can have the sub-list data
>    B.2        type, but ABNF does not support that.
>
>    B.2        Syntax for parmValue confounds over-specification and
>               sub-lists.
>
>    C.8        Length of GIT is wrong.
>
> Taylor           Standards Track -- Expires Sep 2000                 3
>                        Megaco/H.248 Corrections             March 2000
>
>    D.1.4      Second para: transaction originator may not have received
>               TransactionPending response(s) because they were lost,
>               and may therefore not know that responder is expecting
>               immediate acknowledgement of the TransactionReply.
>
>    E.1.2      Granularity of signal completion event is too coarse as a
>               mechanism to detect signalling failures.
>
>    E.9.2      Stated hook state reporting behaviour has race condition
>               where same transition could be reported twice.
>
>    E.10.2     Wording of condition for generating cmp event with
>               "success" does not cover case where test also requires
>               successful removal of tone.
>
> 5. Errors For Which Corrections Are Stated
>
>    This is the only section which will remain in this document after
>    the IESG has approved the combination of [2] and the corrections
>    stated below.  It describes the errors and ambiguities which have
>    been found in [2], along with the corrections they require.
>
>    Section    Issue                           Resolution
>
>    2          Q.724 is not used.              Delete from list of
>                                               references.
>    4          BRI is not used.                Delete from list of
>                                               abbreviations.
>    2, C       Leave Recs. referred to in      Do that.
>               Annex C undated, implying
>               latest issue.
>
> Taylor           Standards Track -- Expires Sep 2000                 4
>                        Megaco/H.248 Corrections             March 2000
>
>    6.2.4      Says that property values set   Add text to first para
>               in Null context are             third sentence: "Most
>               remembered and reinstated       properties have default
>               when termination returns to     values, which are
>               Null.  Contradicts latest       explicitly defined in
>               text in 7.2.3.                  this standard or set by
>                                               provisioning."  Delete
>                                               first para fourth
>                                               sentence, which read:
>                                               "The default value of a
>                                               property of a physical
>                                               Termination can be
>                                               changed by setting it to
>                                               a different value when
>                                               the Termination is in
>                                               the null Context."
>    6.2.4      DigitMap entry in table makes   Change existing text to
>               explicit reference to DTMF      new one as follows:
>               tones.                          "Defines patterns
>                                               against which sequences
>                                               of a specified set of
>                                               events are to be matched
>                                               so they can be reported
>                                               as a group rather than
>                                               singly."
>    7.1,       The order in which              Add text stating that
>    A.2        descriptors are processed       descriptors are
>               within a command matters, but   processed in the order
>               is not clear.  Moreover, it     in which they are
>               is fixed in the ASN.1 but       provided.  Change ASN.1
>               variable in the ABNF.           in Annex A.2 to impose
>                                               ordering as suggested by
>                                               John Segers ("Descriptor
>                                               processing order", Wed
>                                               15/03/00)
>    7.1.5,     Text allows CHOOSE for          Change ABNF:
>    B.2        property values in              propertyParm = pkgdName
>               TerminationStateDesc, but       ( "$" / parmValue)
>               ABNF does not.
>    7.1.6,     Text indicates use of "true"    Add comment in B.2 that
>    B.2        and "false" values while ABNF   "true" in text
>               uses "on" and "off"             corresponds to "on" in
>                                               ABNF, and "false"
>                                               corresponds to "off".
>    7.1.8      Last bulleted item should       Add "loopback".
>               include "loopback" in list of
>               possible states.
>
> Taylor           Standards Track -- Expires Sep 2000                 5
>                        Megaco/H.248 Corrections             March 2000
>
>    7.1.9      EventDM is part of syntax but   Add text: "If a digit
>               not mentioned in section.       map is required in the
>                                               EventsDescriptor,
>                                               EventDM is used to carry
>                                               either the name or the
>                                               value of the digit map.
>                                               See section 7.1.14."
>    7.1.9      Case 1, step 2(a) is both       Fix separation of
>               incorrectly formulated and      paragraphs.  Change step
>               incorrectly formatted.          2(a) to read: "While
>               Existing logic may result in    waiting for a new
>               an infinite loop.               EventsDescriptor, any
>                                               events detected which
>                                               appear in the current
>                                               EventsBufferDescriptor
>                                               will be placed in the
>                                               EventBuffer.  When a new
>                                               EventDescriptor is
>                                               received, event
>                                               processing repeats from
>                                               step 1."
>    7.1.13     Missing "extension"             Add missing component.
>               component.
>    7.1.14     Item 5 in second numbered       Add the words "and it
>               list  understates conditions    has been fully matched"
>               for digit map completion when   to the existing sentence
>               single candidate remains.
>
>    7.1.18     Third bullet attached to        Delete the clause ";
>               third para: says loopback       loopbacks are created by
>               achieved by manipulating        setting the
>               TerminationMode, which no       TerminationMode"
>               longer has that name.
>    7.2.5      Fails to indicate what          Add the following text:
>               AuditValue for                  "EventBuffer returns the
>               EventBufferDescriptor returns   set of events and
>                                               associated parameter
>                                               values currently enabled
>                                               in the
>                                               EventBufferDescriptor."
>    7.2.5,     Text and ASN.1 allow return     Fix production
>    B.2        of results involving multiple   contextTerminationAudit
>               contexts, but ABNF does not.    by allowing return of
>                                               list of context-specific
>                                               results as an
>                                               alternative.
>
> Taylor           Standards Track -- Expires Sep 2000                 6
>                        Megaco/H.248 Corrections             March 2000
>
>    7.2.5,     Does not indicate how an        Change syntax of
>    A.2,       audit of digit maps returns     DigitMapDescriptor to
>    B.2        unnamed digit maps.             allow return of unnamed
>                                               digit maps per John
>                                               Seger suggestion ("[Fwd:
>                                               Issues In v16 Draft]",
>                                               Wed 15/03/00).
>    7.2.6      Fails to indicate what
>               AuditCapabilities for           "EventBuffer returns the
>                                               Add the following text:
>               EventBufferDescriptor returns   same information as
>                                               Events."
>    7.2.6,     Inconsistency regarding         Add comment to B.2
>    B.2        permissibility of DigitMap or   "auditItem" production
>               Packages as capability audit    indicating that DigitMap
>               items.                          and Packages are not
>                                               allowed in the
>                                               AuditCapabilities
>                                               command.
>    7.2.8      Paragraph beginning "A          Add text to the
>               ServiceChange Command           offending sentence, so
>               specifying the Root..."         that it reads:
>               immediately following the       "Acknowledgement of the
>               description of ServiceChange    ServiceChange Command
>               Descriptor parameters           completes the
>               erroneously states that the     registration process,
>               response to the ServiceChange   except when the MGC has
>               command terminates the          returned an alternative
>               registration process.  This     ServiceChangeMgcId as
>               is so only if the response      described in the next
>               does not specify an alternate   paragraph."
>               MGC.
>
>    7.3        Text for error code 403         Change text to "Syntax
>               should be consistent with       error in
>               that for 404 and 405.           TransactionRequest"
>
>    8.2.2      Final para has wrong text for   Change to "Syntax Error
>               error code 442.                 in Command"
>
>    11.2       Second paragraph last           Restore original
>               sentence inadvertently          sentence: "If the MG is
>               modified -- duplicates          unable to establish a
>               material in 11.3.               control relationship
>                                               with any MGC, it shall
>                                               wait a random amount of
>                                               time as described in
>                                               Section 9.2 and then
>                                               start contacting its
>                                               primary, and if
>
> Taylor           Standards Track -- Expires Sep 2000                 7
>                        Megaco/H.248 Corrections             March 2000
>
>                                               necessary, its secondary
>                                               MGCs again."
>
>    11.4       Second para: wrong MG is        Change fourth sentence
>               specified as the one to be      to refer to "secondary
>               used after failover.            MG" rather than "primary
>                                               MG".
>    12.1.4     Note says that default          Add TO signals to note.
>               duration should be specified
>               for BR signals.  This also
>               applies to TO signals.
>    A.2        LocalControlDescriptor still
>               contains reserve rather than    separate reserveValue
>               reserveValue and                and reserveGroup
>                                               Replace reserve with
>               reserveGroup.                   Booleans.
>
>    A.2        Assigned object identifier      Add object identifier
>               missing.                        line with content
>                                               "itu-t recommendation h
>                                               248 media-gateway-
>                                               control(0)"
>    B.2        Syntax for parmValue and
>               VALUE together make parsing     in alternativeValue by
>                                               Replace range notation
>               of range ambiguous.             "LSBRKT VALUE COLON
>                                               VALUE RSBRKT"
>    B.2        Error in syntax for
>               digitMapDescriptor: value       digitMapDescriptor =
>                                               Change production:
>               meant to be optional.           DigitMapToken EQUAL
>                                               digitMapName
>                                               [ LBRKT digitMapValue
>                                               RBRKT ]
>    B.2        VersionToken not defined.       Add ABNF:
>                                               VersionToken =
>                                               ("Version" / "V")
>    B.2        DiscardToken not used.          Delete production.
>    C.9        ITC has reference to missing    Delete reference.
>               note 2
>
>    C.9        Not clear that Q.931 Bearer     Specify that values are
>               Capability IE rather than Low   those valid for Bearer
>               Layer Compatibility IE is       Capability IE
>               being used.
>
> Taylor           Standards Track -- Expires Sep 2000                 8
>                        Megaco/H.248 Corrections             March 2000
>
>    D.1        Even in the case of handoff     In the last sentence of
>               or failover, the originating    the first paragraph,
>               MGC needs confirmation that     delete the excepting
>               its command was received.       clause, so that the
>                                               sentence reads:
>                                               "Responses must be sent
>                                               to the address and port
>                                               from which the
>                                               corresponding commands
>                                               were sent."
>    D.1.1      Second para last sentence
>               provides a procedural
>               reference to 8.2.3.  Should
>               refer to UDP-specific
>                                               Add reference to D.1.4.
>               procedures.
>
>    D.1.4      First paragraph, last
>               sentence talks about when to    SHOULD send this
>               send the Transaction Pending    response if they receive
>               response.  When UDP/ALF is in   a repetition of a
>               use, the originator of a        transaction that is
>               transaction may repeat it       still being executed."
>               because it has not received
>               an acknowledgement that the
>               transaction was received.  An
>               appropriate response to a
>               duplicate transaction which
>               is still being processed is
>               to return Transaction
>                                               Add the sentence: "They
>               Pending.
>
>    D.1.5      Last paragraph is equivocal     Change the two sentences
>               about what                      following the phrase "_
>               ServiceChangeReason to use      and it begins its
>               when recovering from loss of    recovery process" to
>               contact; it must always be      read as follows: "The MG
>               "Disconnected".                 shall use a
>                                               ServiceChange with
>                                               ServiceChangeMethod set
>                                               to disconnected so that
>                                               the new MGC will be
>                                               aware that the MG lost
>                                               one or more
>                                               transactions."
>    E.6.2      "Long duration event            Replace with "Z".
>               modifier" is shown as "L" in
>               parameter DigitString --
>               should be "Z".
>
> Taylor           Standards Track -- Expires Sep 2000                 9
>                        Megaco/H.248 Corrections             March 2000
>
>    Appx       Step 20 fails to show a         Add the following to the
>    A.1.2      returned                        Media Descriptor
>               TerminationStateDescriptor      preceding the line
>                                               "Stream = 1_":
>                                               "TerminationState {
>                                               ServiceStates =
>                                               InService,
>                                               EventBufferControl = OFF
>                                               },"
>
> 6. Security Considerations
>
>    This draft is a supplement to [2], which contains the required
>    security section.
>
> 7. References
>
>    [1] RFC 2026
>    [2] draft-ietf-megaco-protocol-07.txt
>    [3] RFC 2119
>
> 8. Acknowledgments
>
>    This draft records the contributions of a number of people on the
>    Megaco list who took the time to read the Megaco/H.248 draft with
>    care and attention.  Thanks to all of them.
>
> 9. Author's Addresses
>
>    Tom Taylor
>    Nortel Networks
>    P.O. Box 3511, Station C
>    Ottawa, Ontario, Canada K1Y 4P7
>    Phone: +1 613 736 0961
>    Email: [email-masked]
>
> Taylor           Standards Track -- Expires Sep 2000                10
>                        Megaco/H.248 Corrections             March 2000
>
> Full Copyright Statement
>
>    "Copyright (C) The Internet Society (date). All Rights Reserved.
>    This document and translations of it may be copied and furnished to
>    others, and derivative works that comment on or otherwise explain it
>    or assist in its implmentation may be prepared, copied, published
>    and distributed, in whole or in part, without restriction of any
>    kind, provided that the above copyright notice and this paragraph
>    are included on all such copies and derivative works. However, this
>    document itself may not be modified in any way, such as by removing
>    the copyright notice or references to the Internet Society or other
>    Internet organizations, except as needed for the purpose of
>    developing Internet standards in which case the procedures for
>    copyrights defined in the Internet Standards process must be
>    followed, or as required to translate it into other languages.
>
>    1  Bradner, S., "Key words for use in RFCs to Indicate Requirement
>       Levels", BCP 14, RFC 2119, March 1997
>
> Taylor           Standards Track -- Expires Sep 2000                11

--
John Segers                                  email: [email-masked]
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954

Issues raised on the Megaco list

This note captures some issues raised on the Megaco list after ITU-T SG16
redetermined H.248.  The issues mentioned here are not mentioned in Tom
Taylor's internet draft draft-ietf-megaco-errata-00.txt.  Some of the
issues mentioned below are closed, which case the resolution is stated, and
some remain open as yet.

Section Issue

2.      Reference to I.363.5 (AAL5) is missing.

        Proposed resolution: add reference.

2.      Reference to RFC 1661 (PPP) is missing.

        Proposed resolution: add reference.

7.1.1   The text refers to "the previous value" of parameters, although
        there may not always be a previous value.

        Proposed resolution: add text saying that initially all parameters
        are empty (see email from Flemming Andreasen 2000/03/28 "Re: V16
        review - Editorial comments".

7.1.9   Seventh paragraph, starting "When the MG receives a command with
        [...]".  The text does not say that the new events descriptor is
        used in processing the buffered events.

        Proposed resolution:  Add a sentence "The buffered events are
        processed using the new events descriptor." after the first
        sentence.

7.1.14  Various points related to digit map processing.  See messages from
        Flemming Andreasen and Tom Taylor on Megaco list, 2000/03/16-17.

7.1.18  Editorial corrections:
        * first bullet list, first entry: change "nor vice versa" to "and
          vice versa";
        * the word "be" is missing from the last sentence of the section.

7.2.3   The bullet list at the end of the section mentions provisioned and
        default values that contradicts the (older) text in section 6.2.4.

A.2     Two errors in the ASN.1 specification.
        * In EventBufferControl, the values ("Off" and "LockStep") are
          capitalized.  The initial caps have to be removed.
        * "IA5STRING" has to be replaced by "IA5String".

B.2     Both "TransactionID" and "TransactionId" are used in the ABNF.
        Strictly speaking, this is not in error, but it is better to use
        "TransactionId" throughout the section.

C.8     Generic Identifier Transport (raised by Keith Drage).
        The Megaco draft specifies four octets for the GIT field, even
        though Q.2941.1 allows up to 29 octets.

        The field was introduced in Megaco to transport binding reference
        per Q.2941.3 between MGC and MG.  The problem is that Q.2941.3 is
        not yet an approved standard and cannot be referenced from
        Megaco/H.248 according to ITU rules.

        Proposed resolution: allow the full 29 octets.

E.5.3   The megaco internet draft has a typo: it says "d1" twice in the
        table, and does not have "d0".

E.13.1  Editorial correction: replace "isrequested" by "is requested".

---

From: Christian Groves <[email-masked]>
Date: Wed, 5 Apr 2000 18:11:06 +1000

G'Day John, Tom, all,

I've gone through the issues list and have a few comments and
suggestions. I've also added a few more items on the bottom of the
email. Please see [CHG] below.

Cheers, Christian

..snip..
> >    6.2.2      Not clear what wildcard union responses look like.
[CHG]  A suggestion:
        Add "ie. Given termination Ta with properties p1=a, p2=b, and
               termination Tb with properties p2=c, p3=d a UNION
               resonse would be T* p1=a, p2=b,c, p3=d"
> >               which parameters are mandatory.
[CHG] This depends on the application I would imagine. Can we really
give an
example of a mandatory parameter. Isn't this a statement of behaviour
rather than what a mandatory parameter is?

> >               or at time of notification.
[CHG] The current text states that "Normally, detection of an event
shall cause active signals to stop". So this is covered.

..snip..
> >               they create response loops.
[CHG] Sounds reasonable

> >               specified as atomic.            means, particularly
[CHG] No roll back

> >    B.2        type, but ABNF does not support that.
[CHG] Isn't a list just an octet string? Does there need to be specific
ABNF. This leads to 12.3. Does a list need to be IANA registered as the
list name will be unique within a package. Proposal: remove last
sentence of 12.3

..snip..
> >               mechanism to detect signalling failures.
[CHG] Unless people have more detailed codes I think we can live with
this. We can in v2 add more enumerations to the list if we need to.

> >               where same transition could be reported twice.
[CHG] Is this in the case of restrart?

> >               successful removal of tone.
[CHG] This is implied. An event stops a signal by default.

> >    been found in [2], along with the corrections they require.
..snip..
> >               include "loopback" in list of
[CHG] Should this be section 7.1.7?

..snip..

John Seger's Notes:
-------------------
>         default values that contradicts the (older) text in section 6.2.4.
[CHG] Isn't the default and provisioned value the same thing in this
case? as per 6.2.4?

Christian's additional comments:
--------------------------------
Chp 6.2.5 para 1
Change:
Root thus may have properties and events
To:
Root thus may have properties, statistics and events
Reason: Can't root have statistics?
Chp 7.2.4
Add:
The "choose"CHOOSE option is an error, as the Move command may only be
used on existing Terminations.
Reason: To align with the subtract command

Chp 7.2.8
Change:
The ServiceChangeReason parameter specifies the reason why the
ServiceChange has or will occur.  It consists of an alphanumeric token
(IANA registered) and an explanatory string.
to:
The ServiceChangeReason parameter specifies the reason why the
ServiceChange has or will occur.  It consists of an alphanumeric token
(IANA registered) and an optional explanatory string.
Reason: The explantory string is optional in the encoding.

Chp 7.2.8 point 1
Change:
…establishing new connections using the specified terminations and
should attempt
Reason:
Reads like NO new connections should be made where no connections should
be made on the specified terminations in the ServiceChange
Chp 8 Last Paragraph
Change:
Applications SHOULD implement an application level timer per
transaction.
to:
Applications SHOULD implement a protocol timer per transaction.
Reason:
Its not really timing the application but the protocol

Chp 12.1.2
Add:
… independent properties. Properties may also be defined in Local and
Remote descriptors.
Reason:
Reads like properties can only be defined on local control and
termination state.

A.1
Change:
TerminationID 0xFFFFFFFFFFFFFFFF SHALL be used to indicate the ROOT
Termination.
to:
TerminationID with all bits set to 1 (eg. 0xFFFFFFFFFFFFFFFF) SHALL be
used to indicate the ROOT Termination.
Reason:
A terminationID can be from 1bit to 6octets long. If your termination
scheme is only one octet it makes no sense to use 6 octets for ROOT.

E.2.1
Add:
Properties shall be defined in Local Control Descriptor
Reason:
Root properties are not defined for any descriptor

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 5 Apr 2000 18:11:36 -0700

Hi Tom

Some comments below. In addition to what you have here, I think we still have
one or two open issues with the digit maps - I'll resend the latest e-mail
exchange we had on this.

Regards

            Flemming

>               recapitulate definition of

I read it slightly different as it seems to imply "KeepActive" semantics,
regardless of whether the flag is present or not (not an issue, just want to
clarify)

>    6.2.2      Not clear what wildcard union responses look like.

Proposed resolution:        Add an example somewhere.

>               which parameters are mandatory.

Proposed resolution:    Add a table.

>               or at time of notification.

Proposed resolution:    At time of processing, i.e. if an event specified in the
active Events Descriptor is processed, signals on the termination stop (unless
KeepActive is specified).

>               completion event detection.

I didn't follow that - can you elaborate ?

>               reports events captured in current dial string of active

Proposed solution:        Given the way digits collected according to digit maps
will be reported in the end, it would seem consistent to not report the current
dial string. Alternatively, I guess you could include a DigitMap Completion
event with a digitstring, but without a Termination Method.

>               they create response loops.

Agreed.

>               specified as atomic.            means, particularly

Proposed resolution:        Get Brian Rosen to type up something :-)

>               immediate acknowledgement of the TransactionReply.

Proposed resolution:        Add an optional field in the TransactionReply
allowing the responder to indicate if an immediate ack is expected or not.

>               mechanism to detect signalling failures.

Proposed resolution:    Define an EventsDescriptor parameterfor the Signal
Completion event allowing the MGC to specify which Termination Methods it's
interested in.

>               where same transition could be reported twice.

Proposed resolution:    Add the following event parameters for the onhook and
offhook events:
1. No expected hook-state, just report next transition
2. Event indicates expected hook-state, report if hook-state differs (current
text)
3. Event indicates expected hook-state, let command fail if actual hook-state
differs.

>               successful removal of tone.

(actually E.10.5)

Proposed resolution:        Replace "If the return tone is detected before the
signal times out" with "If the test succeeds before the signal times out"

>               variable in the ABNF.           in Annex A.2 to impose

Solves the "audit order issue" in 7.2.9, but not quite sure what that means in
lieu of atomic command execution.

>               include "loopback" in list of

Just to clarify:        Last bulleted item in the second last bullet list.

>               not mentioned in section.       map is required in the

When is a digit map required in the EventsDescriptor ?

>               EventBufferDescriptor returns   same information as

Not sure that's entirely accurate since EventBuffer is a sequence of Observed
Events

>               items.                          and Packages are not

I still don't understand how digit maps can apply to all terminations,
regardless of type (e.g. consider video)

>               material in 11.3.               control relationship

First paragraph actually.

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

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 5 Apr 2000 18:13:16 -0700

Hi Tom

Regards

            Flemming

Agreed.

(actually E.10.5)

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 5 Apr 2000 21:19:04 -0700

Hi Christian

A couple of comments below

> rather than what a mandatory parameter is?

I don't think so. The application would reside in the MGC, however the MG would
need to know what to when a parameter is omitted, i.e. either retain previous
value or use default value. We really need a table or something that clearly
shows what will happen for each parameter.

> shall cause active signals to stop". So this is covered.

Indeed it does, however it's "only" specified under EventsDescriptor. Consider
the case of lockstep, where you are currently waiting for a new EvetsDescriptor,
and a signal is playing (say because of KeepActive). An event specified in
EventBuffer Descriptor is now detected. On one hand, you could argue, that by
specifying the event in EventBufferDescriptor you would want the synchronization
to occur (although I'm not convinced that holds) regardless of whether that
event is specified in a subsequent Events Descriptor. However, now consider that
the event in the new Events Descriptor is specified with a KeepActive parameter
- you probably didn't want the syncrhonization to occur then.

I spent a fair amount of time going over this earlier today and ended up
convincing myself that the synchronization should occur at time of processing,
although I'll gladly admit that it's not obvious.

> > >               specified as atomic.            means, particularly

Hmm, I think I'm with Brian here.

> this. We can in v2 add more enumerations to the list if we need to.

Please see my e-mail to Tom. I was basically proposing that you can specify
which of the Termination Method's you are interested in by adding Termination
Method as an EventsDescriptor parameter. Any objections ?

> [CHG] Is this in the case of restrart?

No. Please see my e-mail to Tom.

> [CHG] This is implied. An event stops a signal by default.

Actually, it should have referred to E.10.5 (my fault), where it specifies
something different. Please see my e-mail to Tom

> [CHG] Should this be section 7.1.7?

I disagree. It really is an application level timer so I don't see anything
wrong with the sentence.

> Root properties are not defined for any descriptor

-- Flemming

---

From: Christian Groves <[email-masked]>
Date: Mon, 10 Apr 2000 13:47:03 +1000

G'Day Flemming,

Please below [CHG2]

Cheers, Christian

> shows what will happen for each parameter.
[CHG2] I agree that somewhere you'll need to specify what the MG does
with a mandatory property but is H248 really the place. I would like
that a profile or much document would be the place for this.

> although I'll gladly admit that it's not obvious.
[CHG] After going through the logic above I see what has happened when
we didn't have the event buffer in H248 it was the time of detection at
the media GW. With the introduction of the eventBuffer its the time of
detection in the eventBuffer (otherwise known as processing) :-). To me
its still detection but if people want to clarify it I don't have a
problem.

..snip..
> I disagree. It really is an application level timer so I don't see anything
[CHG] OK. Dropped.