rfc2886.txt

中、英文RFC文档大全打包下载完全版 .

   Resolution: Change production:
   digitMapDescriptor = DigitMapToken EQUAL digitMapName
                [ LBRKT digitMapValue RBRKT ]

   Issue: VersionToken not defined.

   Resolution: Add ABNF:       VersionToken =  ("Version" / "V")

   Issue: DiscardToken not used.

   Resolution: Delete production.

   Section: Annex C
   ----------
   Issue: alignment of sub-octet fields within the octet is not
   indicated.

   Resolution: add note that fields of sub-octet length are placed in
   the low-order bits of the octet.

   Section: Annex C, ATM-related sections C.4, C.7, C.8, C.10
   ----------
   Issue: direction of flow is segregated by outgoing (Remote
   descriptor) and incoming (Local descriptor).  Since forward and
   backward properties will not both reside in the same descriptor, need
   only the one set of properties applicable to both directions.

   Resolution: replace with a single set of properties.

   Issue: miscellaneous problems of parameter specifications
   inconsistent with the relevant standards, unused parameters,
   distinction between ATM Forum and ITU-T usages, missing references.

   Resolution: fix them.

   Section: Annex C.8 "ATM AAL1"
   ----------
   Issue: Length of GIT is wrong.

   Resolution: ITU-T procedural problem, to be resolved by SG 16.
   Probable solution is to allow 29 octets, event though the relevant
   form requires only four octets.

   Section: Annex C.9 "Bearer Capabilities"
   ----------
   Issue: ITC has reference to missing note 2

   Resolution: Delete reference.



Taylor                      Standards Track                    [Page 15]

RFC 2886                     Megaco Errata                   August 2000


   Issue: Not clear that Q.931 Bearer Capability IE rather than Low
   Layer Compatibility IE is being used.

   Resolution: Specify that values are those valid for Bearer Capability
   IE

   Section: Annex D.1 "Transport over IP/UDP using Application Level
   Framing"
   ----------
   Issue: Even in the case of handoff or failover, the originating MGC
   needs confirmation that its command was received.

   Resolution: In the last sentence of the first paragraph, delete the
   excepting clause, so that the sentence reads: "Responses must be sent
   to the address and port from which the corresponding commands were
   sent."

   Section: Annex D.1.1 "Providing At-Most-Once Functionality"
   ----------
   Issue: Second para last sentence provides a procedural reference to
   8.2.3.  Should refer to UDP-specific procedures.

   Resolution: Add reference to D.1.4.

   Section: Annex D.1.3 "Repeating Requests, Responses and
   Acknowledgements"
   ----------
   Issue: Make exponential backoff in the face of congestion mandatory.

   Resolution: To the paragraph just before the note, which begins "The
   specification purposely avoids specifying any value for the
   retransmission timers...", add the following sentence:

   "Implementations SHALL ensure that the algorithm used to calculate
   retransmission timing performs an exponentially increasing backoff of
   the retransmission timeout for each retransmission or repetition
   after the first one."

   In the paragraph in the middle of the note beginning "After any
   retransmission ...", capitalize the word SHOULD to emphasize the
   importance of the steps which follow.

   Issue: Last paragraph is equivocal about what ServiceChangeReason to
   use when recovering from loss of contact; it must always be
   "Disconnected".






Taylor                      Standards Track                    [Page 16]

RFC 2886                     Megaco Errata                   August 2000


   Resolution: Change the two sentences following the phrase "_ and it
   begins its recovery process" to read as follows: "The MG 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."

   Section: Annex D.1.4 "Provisional responses"
   ----------
   Issue: First paragraph, last sentence talks about when to send the
   Transaction Pending response.  When UDP/ALF is in use, the originator
   of a transaction may repeat it 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 Pending.

   Resolution: Add the sentence: "They SHOULD send this response if they
   receive a repetition of a transaction that is still being executed."

   Issue: 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.

   Resolution: add an optional field to TransactionReply allowing the
   responder to indicate if an immediate ACK is required.  Add text in
   the section indicating that when the responder has sent a provisional
   response, it shall also set the indicator in the final transaction
   reply to indicate that an immediate acknowledgement is required.

   Section: Annex E "Basic Packages"
   ----------
   Issue: package numbering does not follow order of presentation.

   Resolution: renumber packages to follow order of numbering.

   Section: Annex E.2.1 "Base Root Package -- Properties"
   ----------
   Issue: the descriptor in which these properties occur is not
   specified.

   Resolution: in each case, indicate that the property is defined in
   the TerminationState descriptor.

   Section: Annex E.6.2 "DTMF detection Package -- Events"
   ----------
   Issue: "Long duration event modifier" is shown as "L" in parameter
   DigitString -- should be "Z".

   Resolution: Replace with "Z".



Taylor                      Standards Track                    [Page 17]

RFC 2886                     Megaco Errata                   August 2000


   Section: Annex E.9.2 "Analog Line Supervision Package -- Events"
   ----------
   Issue: Stated hook state reporting behaviour has race condition where
   same transition could be reported twice.

   Resolution: add an optional EventsDescriptor parameter and an
   optional ObservedEvents parameter to each of the on-hook and off-hook
   events.  Delete the second sentence of the existing event description
   (which indicates that the event is always reported if the hook state
   has already been achieved).

   The EventsDescriptor parameter is described as follows:

   Strict Transition
         ParameterID: strict (0x0001)
         Type: enumeration
         Possible values:
             "exact" means that only an actual hook state transition
             to on-hook (off-hook) is to be recognized

             "state" means that the event is to be recognized
             either if the hook state transition is detected or if the
             hook state is already on-hook (off-hook).  This is the
             default value if "strict" is unspecified.

             "failWrong" means that if the hook state is already what
             the transition would imply, the command fails and an error
             is reported [error code to be defined in the package].

   The ObservedEvents parameter is described as follows:

   Initial State
         ParameterID: init (0x0002)
         Type: Boolean
         Possible values:
             true/"ON" means that the event was reported because the
             line was already on-hook (off-hook) when the events
             descriptor containing this event was activated

             false/"OFF" means that the event represents an actual
             state transition to on-hook (off-hook)

   Section: Annex E.10.3 "Basic Continuity Package -- Signals"
   ----------
   Issue: The rsp signal should continue until the MGC tells the MG to
   stop applying it.

   Resolution: change the type of signal from Timeout to ON/OFF.



Taylor                      Standards Track                    [Page 18]

RFC 2886                     Megaco Errata                   August 2000


   Section: Annex E.10.5 "Basic Continuity Package -- Procedures"
   ----------
   Issue: Wording of condition for generating cmp event with "success"
   does not cover case where test also requires successful removal of
   tone.

   Resolution: In the second paragraph of E.10.5 (dealing with test
   initiation), add the words "and any other required conditions are
   satisfied" in the second sentence, as part of the condition upon
   which success is reported.  Replace the third paragraph (dealing with
   test response) with the following text:

   "When a MGC wants the MG to respond to a continuity test, it sends a
   command to the MG containing a signals descriptor with the rsp
   signal. Upon reception of a command with the rsp signal, the MG
   either applies a loop-back or (for 2-wire circuits) awaits reception
   of a continuity test tone.  In the loop-back case, any incoming
   information shall be reflected back as outgoing information.  In the
   2-wire case, any time the appropriate test tone is received, the
   appropriate response tone should be sent.  The MGC will determine
   when to remove the rsp signal."

   Section: Appendix A.1.2 "Example -- Collecting Originator Digits and
   Initiating Termination"
   ----------
   Issue: Step 3 uses a now-obsolete package DS0 for echo cancellation.

   Resolution: replace with echo cancellation via package TDM.

   Issue: Step 20 fails to show a returned TerminationStateDescriptor.
   It also contains the erroneous statement that an RTP termination does
   not support events and signals and fails to show a number of other
   descriptors.

   Resolution:
   Delete the sentence containing the erroneous statement.
   Add the following to the Media Descriptor preceding the line "Stream
   = 1_":
   "TerminationState { ServiceStates = InService, EventBufferControl =
   OFF },"

   Add lines showing Events, Signals, and DigitMap descriptors
   following the Media descriptor.

   "Events, Signals, DigitMap,"






Taylor                      Standards Track                    [Page 19]

RFC 2886                     Megaco Errata                   August 2000


4. Security Considerations

   This memo is a supplement to [2], which contains the required
   security section.

5. References

   [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
       9, RFC 2026, October 1996.

   [2] Cuervo, F., Greene, N., Huitema, C., Rayhan, A., Rosen, B. and J.
       Segeret, "Megaco Protocol", RFC 2885, August 2000.

   [3] Bradner, S., "Key Words For Use In RFCs To Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.

6. Acknowledgments

   This memo records the contributions of a number of people on the
   Megaco list and the H.248 faithful in ITU-T Study Group 16 who took
   the time to read the Megaco/H.248 document with care and attention.
   Thanks to all of them.

7. Author's Address

   Tom Taylor
   Nortel Networks
   P.O. Box 3511, Station C
   Ottawa, Ontario, Canada K1Y 4P7

   Phone: [phone]
   EMail: [e-mail]



















Taylor                      Standards Track                    [Page 20]

RFC 2886                     Megaco Errata                   August 2000


8.  Full Copyright Statement

   Copyright (C) The Internet Society (2000).  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 implementation 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 languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Taylor                      Standards Track                    [Page 21]