diff options
Diffstat (limited to 'doc/rfc/rfc2886.txt')
| -rw-r--r-- | doc/rfc/rfc2886.txt | 1179 |
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc2886.txt b/doc/rfc/rfc2886.txt new file mode 100644 index 0000000..bcaf2e4 --- /dev/null +++ b/doc/rfc/rfc2886.txt @@ -0,0 +1,1179 @@ + + + + + + +Network Working Group T. Taylor +Request for Comments: 2886 Nortel Networks +Category: Standards Track August 2000 + + + Megaco Errata + +Status of this Memo + + 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. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +1. Abstract + + This document records the errors found in the Megaco/H.248 protocol + document [2], along with the changes proposed in the text of that + document to resolve them. + +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]. + +3. Errata + + All section numbers are those of the relevant text of [2]. + + Section: 2 "References" + ---------- + Editorial: Add missing references to I.363.5 (AAL5) and RFC 1661 + (PPP). + + Editorial: delete unused reference to Q.724. + + Editorial: Leave Recommendations referred to in Annex C undated, + implying latest issue. + + Editorial: add reference to RFC 2805, the Megaco requirements + document. + + + + +Taylor Standards Track [Page 1] + +RFC 2886 Megaco Errata August 2000 + + + Section: 4 "Abbreviations" + ---------- + Editorial: delete unused abbreviation BRI. + + Editorial: add explanations for GSM and IVR. + + Section: 6.2.2 "TerminationIDs" + ---------- + Issue: Not clear what wildcard union responses look like. + + Resolution: Add the following text: + "ie. Given termination Ta with properties p1=a, p2=b, and + termination Tb with properties p2=c, p3=d a UNION + response would be T* p1=a, p2=b,c, p3=d." + + Section: 6.2.4 "Termination Properties and descriptors" + ---------- + Issue: Says that property values set in Null context are remembered + and reinstated when termination returns to Null. Contradicts latest + text in 7.2.3. + + Resolution: Rewrite the first paragraph from the third sentence + onward, to read: "Most properties have default values, which are + explicitly defined in this standard or in a package (see Section 12) + or set by provisioning. If not provisioned otherwise, all + descriptors except for TerminationState and LocalControl default to + empty/"no value" when a termination is first created or is returned + to the null context. The default contents of the two exceptions are + described in sections 7.1.5 and 7.1.7." + + Issue: DigitMap entry in table makes explicit reference to DTMF + tones, but is also intended to apply to other in-band signalling + systems. + + Resolution: Change existing text to new one as follows: "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." + + Section: 6.2.5 "Root Termination" + ---------- + Issue: Root can have statistics as well as properties and events. + + Resolution: add "statistics" to the fourth sentence of the first + paragraph, listing what is valid for Root. Add "statistics" to what + AuditValue can return for Root. + + + + + + +Taylor Standards Track [Page 2] + +RFC 2886 Megaco Errata August 2000 + + + Section: 7.1 "Descriptors" + ---------- + Issue: it is unclear how to express empty descriptors in responses to + the MGC. + + Proposed resolution: In section 7.1, add the following text after the + sentence: "Descriptors may be returned as output from a command.": + "In any such return of descriptor contents, an empty descriptor is + represented by its name unaccompanied by any list." + + In the ASN.1, add the following choice to the AuditReturnParameter + production: + + "emptyDescriptors AuditDescriptor," + + In the ABNF, add the choice auditItem to the production + auditReturnParameter. + + Section: 7.1.1 "Specifying Parameters" + ---------- + Issue: Third paragraph (discussing unspecified parameters): not clear + which parameters are mandatory. + + Resolution: Replace the first two sentences (each beginning with the + word "unspecified") with the following text: "If a required + descriptor other than the Audit descriptor is unspecified (i.e. + entirely absent) from a command, the previous values set in that + descriptor for that termination, if any, are retained. A missing + Audit descriptor is equivalent to an empty Audit descriptor. The + behaviour of the MG with respect to unspecified parameters within a + descriptor varies with the descriptor concerned, as indicated in + succeeding sections." + + Section: 7.1.6 "Stream Descriptor", ABNF (Annex B.2) + ---------- + Issue: Text indicates use of "true" and "false" values while ABNF + uses "on" and "off" + + Resolution: Add comment in B.2 that "true" in text corresponds to + "on" in ABNF, and "false" corresponds to "off". + + + + + + + + + + + +Taylor Standards Track [Page 3] + +RFC 2886 Megaco Errata August 2000 + + + Section: 7.1.8 "Local and Remote Descriptors" + ---------- + Issue: case where reserveGroup or reserveValue is true, last bulleted + item beginning: "If the Mode property of the LocalControl descriptor + is RecvOnly or SendRecv,...", could also have DSP involvement in the + case of loopback mode. + + Resolution: Add "loopback". + + Section: 7.1.9 "Events Descriptor" + ---------- + Issue: EventDM is part of syntax but not mentioned in section. + + Resolution: Add text: "If a digit map completion event is present or + implied in the EventsDescriptor, EventDM is used to carry either the + name or the value of the associated digit map. See section 7.1.14." + + Issue: 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. Also, + the third paragraph of the section fails to mention these side + effects and limits MG action to notification. + + Resolution: Modify the third paragraph of the section, so that it + reads: "When an event (either newly detected or buffered) is + processed against the contents of an active Events descriptor and + found to be present in that descriptor ("recognized"), the default + action of the MG is to send a Notify command to the MG. Notification + may be deferred if the event is absorbed into the current dial string + of an active digit map (see section 7.1.14). Any other action is for + further study. Moreover, event recognition may cause currently + active signals to stop, or may cause the current Events and/or + Signals descriptor to be replaced, as described at the end of this + section." + + Replace "detection" with "recognition" in the fourth paragraph from + the end, so that it reads: "Normally, recognition of an event shall + cause any active signals to stop. When KeepActive is specified in + the event, the MG shall not interrupt any signals active on the + Termination on which the event is detected." + + In the third-last paragraph, replace all three instances of + "detected" with "recognized". + + Leave the word "detected" as is in the final paragraph. + + + + + + +Taylor Standards Track [Page 4] + +RFC 2886 Megaco Errata August 2000 + + + Issue: Case 1, step 2(a) is incorrectly formulated. Existing logic + may result in an infinite loop. Also, the step excludes side effect + actions such as signal termination. + + Resolution: Modify step 2(a) to read: "If the event in the queue is + in the events listed in the new EventsDescriptor, the MG acts on the + event and removes it from the EventBuffer. The time stamp of the + Notify shall be the time the event was actually detected. The MG + then waits for a new EventsDescriptor. While waiting for a new + EventsDescriptor, any events detected which appear in the current + EventsBufferDescriptor will be placed in the EventBuffer. When a new + EventDescriptor is received, event processing repeats from step 1." + + Section: 7.1.11 "Signals Descriptor" + ---------- + Issue: There is a need for the MGC to be aware of signalling + failures. It is not possible to use the signal completion event to + monitor for signalling failures only, without also having to process + successes. + + Proposed Resolution: In section 7.1.11, replace the current text on + completion notification, beginning: "Finally, the optional parameter + "notifyCompletion" ..." and continuing to the end of the paragraph + with the following text: + + "Finally, the optional parameter "notifyCompletion" allows a MGC to + indicate the circumstances under which it wishes to be notified when + the signal finishes playout. The possible cases are that the signal + timed out, that it was interrupted by an event, that it was halted + when a Signals descriptor was replaced, or that it stopped or never + started for other reasons. If "notifyCompletion" is absent, + notification is generated in the "other reasons" case only. For + reporting to occur the signal completion event (see section E.1.2) + must be enabled in the currently active Events descriptor." + + In Annex A.2, make notifyCompletion a BIT STRING with the four cases. + In B.2, make it a parameter consisting of a name and a list of values + representing the possible completion methods. + + Section: 7.1.13 "ServiceChange Descriptor" + ---------- + Issue: Missing "extension" component in the API. + + Resolution: Add missing component. + + + + + + + +Taylor Standards Track [Page 5] + +RFC 2886 Megaco Errata August 2000 + + + Section: 7.1.14 "DigitMap Descriptor" + ---------- + Editorial: add the following subsections. + + 7.1.14.1 DigitMap definition, creation, modification and termination + (before first paragraph) + + 7.1.14.2 DigitMap Timers (after the first bullet list) + + 7.1.14.3 DigitMap syntax (before the long paragraph starting "The + formal syntax of the digit map [...]") + + 7.1.14.4 DigitMap completion event (before the paragraph starting "A + digit map is active while the events descriptor [...]") + + 7.1.14.5 DigitMap procedures (before the sentence "Pending + completion, successive events shall be processed [...]", preceding + the numbered list) + + 7.1.14.6 DigitMap activation (after the numbered list) + + 7.1.14.7 Interaction of DigitMap and event processing (before the + next paragraph, starting "While the digit map is activated, [...]") + + 7.1.14.8 Wildcards (before the the next paragraph, starting "Note + that if a package contains [...]") + + 7.1.14.9 Example (before the example) + + Issue: incorrect statements regarding the interaction of the dot + symbol with default timing rules. + + Resolution: last sentence of the paragraph beginning "The letter "x" + is used as a wildcard, ..." should be modified to read: "As a + consequence of the third timing rule above, inter-event timing while + matching a terminal dot symbol uses the short timer by default." In + the next paragraph, the third sentence, which begins: "A timer + specifier following a dot ...", should be deleted. + + Issue: Step 5 in second numbered list understates conditions for + digit map completion when single candidate remains. + + Resolution: Add the words "and it has been fully matched" to the + existing sentence. Also remove the parenthetical remark: "... + (because the candidate set still contains more than one alternative + event sequence)" from step 6. + + + + + +Taylor Standards Track [Page 6] + +RFC 2886 Megaco Errata August 2000 + + + Issue: Not clear when unmatched events are recognized and trigger + side effects (e.g. signal termination). + + Resolution: Modify the final sentence of the paragraph following + procedural step 6 to read as follows: "Normal event behaviour (e.g. + stopping of signals unless the digit completion event has the + KeepActive flag enabled) continues to apply for each such event + detected, except that + + . the events in the package containing the specified digit map + completion event other than the completion event itself are not + individually notified, and + . an event which triggers a "partial match" completion is not + recognized and therefore has no side effects until reprocessed + following the recognition of the digit map completion event." + + Issue: the last paragraph before the example is misleading if the + package containing the digit map completion event is different from + the package containing the actual digits. + + Resolution: qualify the second sentence of the paragraph as follows: + "Regardless of whether a digit map is activated, if the package also + contains the digit events themselves, this form of event + specification ...". + + Section: 7.1.18 "Topology Descriptor" + ---------- + Issue: Third bullet attached to third para: says loopback achieved by + manipulating TerminationMode, which no longer has that name. + + Resolution: Delete the clause "; loopbacks are created by setting the + TerminationMode" + + Section: 7.2 + ---------- + Issue: The order in which descriptors are processed within a command + matters, but is not clear. Moreover, it is fixed in the ASN.1 but + variable in the ABNF. + + Resolution: Add text stating that descriptors are processed in the + order in which they are provided. Change ASN.1 in Annex A.2 to allow + the MGC to specify ordering: + + + + + + + + + +Taylor Standards Track [Page 7] + +RFC 2886 Megaco Errata August 2000 + + + AmmRequest ::= SEQUENCE + { + terminationID TerminationIDList, + descriptors SEQUENCE OF AmmDescriptor, + -- At most one descriptor of each type (see AmmDescriptor) + -- allowed in the sequence + ... + } + + AmmDescriptor ::= CHOICE + { + mediaDescriptor MediaDescriptor, + modemDescriptor ModemDescriptor, + muxDescriptor MuxDescriptor, + eventsDescriptor EventsDescriptor, + eventBufferDescriptor EventBufferDescriptor, + signalsDescriptor SignalsDescriptor, + digitMapDescriptor DigitMapDescriptor, + auditDescriptor AuditDescriptor, + ... + } + + Section: 7.2.3 "Subtract" + ---------- + Issue: cannot use the CHOOSE wildcard for terminationId of a Subtract + command. + + Resolution: add this qualification to the second sentence, which + indicates that terminationId may be wildcarded. + + Section: 7.2.4 "Move" + ---------- + Issue: cannot use the CHOOSE wildcard for terminationId of a Move + command. + + Resolution: add this qualification to the second sentence, which + indicates that terminationId may be wildcarded. + + Section: 7.2.5 "AuditValue" + ---------- + Issue: Not clear whether AuditValue of ObservedEventsDescriptor + reports events captured in current dial string of active digit map. + + Resolution: Add text to indicate that if a digit map is active and + ObservedEventsDescriptor is specified the response to an AuditValue + includes a digit map completion event which shows the current dial + string but does not show a termination method. + + + + +Taylor Standards Track [Page 8] + +RFC 2886 Megaco Errata August 2000 + + + Issue: Fails to indicate what AuditValue for EventBufferDescriptor + returns + + Resolution: Add the following text: "EventBuffer returns the set of + events and associated parameter values currently enabled in the + EventBufferDescriptor." + + Issue: not clear whether wildcarded context includes the null + context. + + Resolution: add statement that ALL as a contextID does not include + the null context. + + Issue: the text of 7.2.5 allows retrieval of multiple digit maps with + one AuditValue command if the terminationId is ALL. Moreover, + earlier text in the Annex anticipates that multiple instances of a + descriptor may be returned. The comment in front of production + auditReturnParameter in Annex B.2 contradicts this text. Note that + Annex A has no restriction on the number of instances of any + descriptor in either a command or a response. + + Proposed Resolution: delete the"at-most-once" comment preceding ABNF + production auditReturnParameter. + + Issue: Does not indicate how an audit of digit maps returns unnamed + digit maps. + + Resolution: Change syntax of DigitMapDescriptor to allow return of + unnamed digit maps as follows: + + digitMapDescriptor = DigitMapToken EQUAL + ( (LBRKT digitMapValue RBRKT) + / (digitMapname [ LBRKT digitMapValue RBRKT ]) + ) and + + DigitMapDescriptor ::= SEQUENCE { + digitMapName DigitMapName OPTIONAL, + digitMapValue DigitMapValue OPTIONAL } + + Issue: the text in section 7.2.5 mentions that using an empty Audit + descriptor with a wildcarded terminationId is a way to get a list of + the terminations in the context. Annex A provides the possibility + that the auditReply may be a contextAuditResult of type + terminationIdList, and Annex B allows for an auditReply containing a + contextTerminationAudit which in turn presents a terminationIdList. + The connection between the text in 7.2.5 and these special forms of + audit result is not clear. Moreover, a note at the beginning of + Annex A section A.2 limits terminationIdList to one terminationId. + + + +Taylor Standards Track [Page 9] + +RFC 2886 Megaco Errata August 2000 + + + Proposed Resolution: add the following text in section 7.2.5 after + the sentence "This may be useful to get a list of TerminationIDs when + used with wildcard.": "Annexes A and B provide a special syntax for + presenting such a list in condensed form, such that the AuditValue + command tag does not have to be repeated for each terminationId." + Also, in the Note at the beginning of section A.2 of Annex A, provide + an exception on the length of type TerminationIdList when used in + contextAuditResult. + + Section: 7.2.6 "AuditCapabilities" + ---------- + Issue: Fails to indicate what AuditCapabilities for + EventBufferDescriptor returns + + Resolution: Add the following text: "EventBuffer returns the same + information as Events." + + Issue: Inconsistency regarding permissibility of DigitMap or Packages + as capability audit items. + + Resolution: Add comment to B.2 "auditItem" production indicating that + DigitMap and Packages are not allowed in the AuditCapabilities + command. + + Section: 7.2.8 "ServiceChange" + ---------- + Issue: In point 1) describing the Graceful ServiceChange method, the + scope of the recommendation against new connections is unclear. + + Resolution: at the end of the first sentence, add the phrase "on the + termination(s) affected by the ServiceChange command". + + Issue: the explanatory string associated with ServiceChangeReason is + optional in the syntax, but not in the text. + + Resolution: add "optional" before "explanatory string" in the + explanation of the ServiceChangeReason" parameter. + + Issue: Paragraph beginning "A ServiceChange Command specifying the + Root..." immediately following the description of ServiceChange + Descriptor parameters erroneously states that the response to the + ServiceChange command terminates the registration process. This is + so only if the response does not specify an alternate MGC. + + Resolution: Add text to the offending sentence, so that it reads: + "Acknowledgement of the ServiceChange Command completes the + registration process, except when the MGC has returned an alternative + ServiceChangeMgcId as described in the next paragraph." + + + +Taylor Standards Track [Page 10] + +RFC 2886 Megaco Errata August 2000 + + + Section: 7.3 "Command Error Codes" + ---------- + Issue: Text for error code 403 should be consistent with that for 404 + and 405. + + Resolution: Change text to "Syntax error in TransactionRequest" + + Issue: There should be no error responses to TransactionReply or + TransactionPending, lest they create response loops. + + Resolution: Delete codes 404, 405, 461-467 + + Section: 8 "Transactions", A.2 + ---------- + Issue: state is unclear if a command fails. + + Resolution: add the following text: "If a command fails, the MG + shall as far as possible restore the state which prevailed prior to + the attempted execution of the command before continuing with + transaction processing." + + Section: 8.1.1 "Transaction Identifiers" + ---------- + Issue: need a transaction identifier to use when reporting a syntax + error such that the identifier is unavailable. + + Resolution: add text reserving transionId = 0 for this purpose. + + Section: 8.1.2 "Context Identifiers" + ---------- + Issue: ALL as a context identifier does not include the null context. + + Resolution: add text to indicate that exclusion in the final sentence + of the section. + + Section: 8.2.2 "TransactionReply" + ---------- + Issue: Final para has wrong text for error code 442. + + Resolution: Change to "Syntax Error in Command" + + Section: 10.2 "Interim AH Scheme", B.2 + ---------- + Issue: The interim AH header can actually be as short as 24 hex + digits (per RFCs 2403, 2404 which are indirectly referenced). It is + also unclear whether it is the source or destination UDP port which + is prepended in the calculation. + + + + +Taylor Standards Track [Page 11] + +RFC 2886 Megaco Errata August 2000 + + + Resolution: Change 10.2 second para, second-last sentence to specify + the destination port, in consistency with IPSEC. In Annex B.2, + change lower count for production AuthData to 24 from 32. + + Section: 11.2 "Cold Start" + ---------- + Issue: First paragraph last sentence inadvertently modified -- + duplicates material in 11.3. + + Resolution: Restore original sentence: "If the MG is unable to + establish a control relationship with any MGC, it shall wait a random + amount of time as described in Section 9.2 and then start contacting + its primary, and if necessary, its secondary MGCs again." + + Section: 11.4 "Failure Of an MG" + ---------- + Issue: Second para: wrong MG is specified as the one to be used after + failover. + + Resolution: Change fourth sentence to refer to "secondary MG" rather + than "primary MG". + + Section: 12.1.2 "Properties" + ---------- + Issue: As indicated in 6.2.4, Properties occur in other descriptors + besides LocalControl and TerminationState. + + Resolution: after the sentence mentioning TerminationState, add + another sentence: "Although these are the most common cases, it is + also possible for a property to be defined for other descriptors." + + Section: 12.1.4 "Signals" + ---------- + Issue: Note says that default duration should be specified for BR + signals. This also applies to TO signals. + + Resolution: Add TO signals to note. + + Section: 12.2 "Guidelines to defining Properties, Statistics and + Parameters to Events and Signals", B.2 + ---------- + Issue: Text indicates that statistics can have the sub-list data + type, but ABNF does not support that. + + Resolution: qualify the sublist type by adding the note: "(not + supported for statistics)". + + + + + +Taylor Standards Track [Page 12] + +RFC 2886 Megaco Errata August 2000 + + + Section: Annex A.1, ASN.1 Syntax + ---------- + Issue: the ASN.1 uses the values 0x0, 0xFFFFFFFE, and 0xFFFFFFFF for + the NULL context, a wildcard CHOOSE of context, and a wildcard ALL of + context respectively. Because of the possibility of a switch between + binary and text encoding for messages relating to the same context, + these values should be reserved in the text encoded syntax. + + Resolution: Add a comment preceding the ContextID production in Annex + B.2 indicating that these values are reserved. + + Section: Annex A.2, ASN.1 Syntax + ---------- + Issue: sloppy ASN.1 -- in production EventBufferControl the values + "off" and "lockstep" should not be capitalized, and IA5STRING in + production NonStandardIdentifier should be IA5String. Both + TransactionID and TransactionId are used. A number of productions + need ellipses to express extensibility. + + Resolution: fix them. + + Issue: syntax for PropertyParm does not support sub-lists (i.e. + parameters supporting multiple values simultaneously) + + Resolution: add a third choice to extrainfo in PropertyParm as + follows: + + extraInfo CHOICE + { + relation Relation, + range BOOLEAN, + sublist BOOLEAN + } OPTIONAL + + and add an appropriate note to the preceding comments. + + Issue: LocalControlDescriptor still contains reserve rather than + reserveValue and reserveGroup. + + Resolution: Replace reserve with separate reserveValue and + reserveGroup Booleans. + + Issue: EventBufferDescriptor is incorrectly portrayed as a SEQUENCE + OF ObservedEvent. + + Resolution: replace with the following productions: + + + + + +Taylor Standards Track [Page 13] + +RFC 2886 Megaco Errata August 2000 + + + EventBufferDescriptor ::= SEQUENCE OF EventSpec + + EventSpec ::= SEQUENCE { + pkgdName PkgdName, + streamID StreamID OPTIONAL, + evParList SEQUENCE OF EventParameter } + + Issue: Assigned object identifier missing. It is usually present as + a matter of convention. + + Resolution: Add object identifier line in the message header with + content: + "itu-t recommendation h 248 media-gateway-control(0)" Delete the + version field, which this makes redundant. + + Issue: the T.35 country code in the H221NonStandard production does + not have the right structure. + + Resolution: fix it. + + Section: Annex B.2, ABNF Syntax + ---------- + Issue: Syntax for parmValue and VALUE together make parsing of range + ambiguous. Furthermore, sub-lists and sets of alternative values + have the same syntax, introducing possible ambiguity + + Resolution: Replace production alternativeValue by the following: + "alternativeValue = ( VALUE + / LSBRKT VALUE *(COMMA VALUE) RSBRKT ; sub-list + / LBRKT VALUE *(COMMA VALUE) RBRKT ; alternatives + / LSBRKT VALUE COLON VALUE RSBRKT ) ; range" + + Issue: EventBufferDescriptor content mistakenly shown as a sequence + of observedEvent. + + Resolution: replace the production for eventBufferDescriptor with the + following productions: + + eventBufferDescriptor = EventBufferToken LBRKT [ eventSpec + *( COMMA eventSpec ) ] RBRKT + + eventSpec = pkgdName [ LBRKT eventSpecParameter + *( COMMA eventSpecParameter ) RBRKT ] + + eventSpecParameter = ( eventStream / eventOther ) + + Issue: Error in syntax for digitMapDescriptor: value meant to be + optional. + + + +Taylor Standards Track [Page 14] + +RFC 2886 Megaco Errata August 2000 + + + 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: +1 613 736 0961 + EMail: taylor@nortelnetworks.com + + + + + + + + + + + + + + + + + + + +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] + |