RFC 2886

Megaco Errata

📅 published August 2000, from ietf

Megaco Errata 🦋

RFC 2886 is titled Megaco Errata. T. Taylor from Nortel Networks wrote it, it's a Standards Track doc, and it's dated August 2000 🎀. It doesn't list anything it obsoletes or updates, so there's no drama there 💅.

Status of this Memo

Okay so this doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶. If you want the official standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited ✨.

Copyright (C) The Internet Society (2000). All Rights Reserved.

1. Abstract 🌸

This doc is basically a list of the mistakes found in the Megaco/H.248 protocol document [2], plus the fixes that were proposed in the text of that doc to sort them out 🔧.

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]. So if a number looks off, it's pointing back to that doc, not this one 🫶.

Section 2 "References" 📚

  • Editorial: Add the missing references to I.363.5 (AAL5) and RFC 1661 (PPP). These were just not there, bestie 😭.
  • Editorial: Delete the unused reference to Q.724 🗑️.
  • Editorial: Leave the Recommendations referred to in Annex C undated, which implies the latest issue 🔥.
  • Editorial: Add a reference to RFC 2805, the Megaco requirements document ✨.

Section 4 "Abbreviations" 💅

  • Editorial: Delete the unused abbreviation BRI.
  • Editorial: Add explanations for GSM and IVR. Nobody should have to guess what those mean 🙈.

Section 6.2.2 "TerminationIDs" 🍓

  • Issue: It wasn't clear what wildcard union responses look like. Honestly, relatable 😭.
  • 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: This section says that property values set in the Null context are remembered and reinstated when a termination returns to Null. That contradicts the latest text in 7.2.3. Major plot hole, no cap 🕳️.
  • Resolution: Rewrite the first paragraph from the third sentence onward, so it reads:
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: The DigitMap entry in the table makes an explicit reference to DTMF tones, but it's also meant to apply to other in-band signalling systems. It's giving tunnel vision 🙄.
  • Resolution: Change the existing text to this new one:
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: The Root can have statistics as well as properties and events, and the text didn't say so 📊.
  • Resolution: Add "statistics" to the fourth sentence of the first paragraph, listing what's valid for Root. Also add "statistics" to what AuditValue can return for Root ✨.

Section 7.1 "Descriptors" 🦋

  • Issue: It's unclear how to express empty descriptors in responses to the MGC. Like, how do you even show "nothing here" 🥲?
  • 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: The third paragraph, which discusses unspecified parameters, doesn't make clear which parameters are mandatory. Big "which one is it" energy 🤔.
  • 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: The text uses "true" and "false" values, but the ABNF uses "on" and "off". Two words for the same vibe, which is confusing 😭.
  • Resolution: Add a comment in B.2 that "true" in the text corresponds to "on" in the ABNF, and "false" corresponds to "off" ✨.

Section 7.1.8 "Local and Remote Descriptors" 🌸

  • Issue: In the case where reserveGroup or reserveValue is true, the last bulleted item begins: "If the Mode property of the LocalControl descriptor is RecvOnly or SendRecv,...". It could also have DSP involvement in loopback mode, and that wasn't mentioned 🔁.
  • Resolution: Add "loopback" ✅.

Section 7.1.9 "Events Descriptor" 🔥

  • Issue: EventDM is part of the syntax but isn't mentioned in the section. Lowkey missing a whole character 🙈.
  • Resolution: Add this 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: It's not clear whether events trigger side effects (for example, stopping a signal on the termination) at the time of detection, at the time of processing (whether or not they're in an active Events Descriptor), or at the time of notification. Also, the third paragraph fails to mention these side effects and limits MG action to notification. So many questions 😵‍💫.
  • Resolution: Modify the third paragraph of the section so 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 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 it is in the final paragraph 💅.
  • Issue: Case 1, step 2(a) is formulated incorrectly. The 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: The MGC needs to be aware of signalling failures. Right now it's not possible to use the signal completion event to monitor only for failures, without also having to process the successes. Unnecessary extra work, periodt 💀.
  • 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: The "extension" component is missing from the API. Yikes 😬.
  • Resolution: Add the missing component ✅.

Section 7.1.14 "DigitMap Descriptor" 🍓

  • Editorial: Add the following subsections, each in the spot described:
    • 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 next paragraph, starting "Note that if a package contains [...]")
    • 7.1.14.9 Example (before the example)
  • Issue: The statements about how the dot symbol interacts with the default timing rules are incorrect 🙃.
  • Resolution: The 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, delete the third sentence, which begins "A timer specifier following a dot ..." 🗑️.

  • Issue: Step 5 in the second numbered list understates the conditions for digit map completion when a single candidate remains. Understated, but make it make sense 🤷‍♀️.
  • 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 ✨.
  • Issue: It's not clear when unmatched events are recognized and trigger side effects (for example, signal termination) 🔍.
  • Resolution: Modify the final sentence of the paragraph following procedural step 6 so it reads 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

okay bestie, we're picking up right where the digit map stuff left off 🧚✨

  • 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 paragraph right before the example is kinda misleading when the package with the digit map completion event isn't the same package as 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: the third bullet, attached to the third paragraph, says loopbacks get made by manipulating TerminationMode, which doesn't even have that name anymore 💀

Resolution: delete the clause "; loopbacks are created by setting the TerminationMode"

Section: 7.2

Issue: the order that descriptors get processed in a command matters, but nobody made it clear 😭 Also it's fixed in the ASN.1 but variable in the ABNF, which is just chaotic.

Resolution: add text stating that descriptors are processed in the order in which they are provided. Change the ASN.1 in Annex A.2 to allow the MGC to specify ordering:

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: you can't use the CHOOSE wildcard for the terminationId of a Subtract command, and that's a whole vibe-kill 🙅‍♀️

Resolution: add this qualification to the second sentence, which indicates that terminationId may be wildcarded.

Section: 7.2.4 "Move"

Issue: same deal here. You can't use the CHOOSE wildcard for the 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: it isn't clear whether an AuditValue of ObservedEventsDescriptor reports the events captured in the current dial string of an 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.

Issue: this one doesn't say 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: it's not clear whether a wildcarded context includes the null context.

Resolution: add a statement that ALL as a contextID does not include the null context.

Issue: the text of 7.2.5 lets you retrieve multiple digit maps with one AuditValue command if the terminationId is ALL. Earlier text in the Annex also expects multiple instances of a descriptor to come back, but the comment in front of the production auditReturnParameter in Annex B.2 contradicts all of that. Also, Annex A has no restriction on how many instances of any descriptor can show up in a command or a response, so the comment is the odd one out 😤

Proposed Resolution: delete the"at-most-once" comment preceding ABNF production auditReturnParameter.

Issue: this doesn't explain how an audit of digit maps returns unnamed digit maps 🧐

Resolution: change the syntax of DigitMapDescriptor to allow the 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: section 7.2.5 says 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 allows the auditReply to be a contextAuditResult of type terminationIdList, and Annex B allows an auditReply containing a contextTerminationAudit, which in turn presents a terminationIdList. The link between the text in 7.2.5 and these special result forms is unclear 🌸 Also, a note at the start of Annex A section A.2 limits terminationIdList to one terminationId, which is a big mood-killer for this use case.

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: this doesn't say what AuditCapabilities for EventBufferDescriptor returns 😭

Resolution: add the following text: "EventBuffer returns the same information as Events."

Issue: it's inconsistent about whether DigitMap or Packages are allowed as capability audit items 🙃

Resolution: add a comment to the 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), which describes 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 attached to ServiceChangeReason is optional in the syntax but not in the text. Inconsistent, bestie 💀

Resolution: add "optional" before "explanatory string" in the explanation of the ServiceChangeReason" parameter.

Issue: the paragraph beginning "A ServiceChange Command specifying the Root..." comes right after the description of the ServiceChange Descriptor parameters, and it wrongly says that the response to the ServiceChange command ends the registration process. That's only true if the response doesn't 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."

Section: 7.3 "Command Error Codes"

Issue: the text for error code 403 should be consistent with the text for 404 and 405 🎀

Resolution: change the text to "Syntax error in TransactionRequest"

Issue: there should be no error responses to TransactionReply or TransactionPending, or they could create response loops 🔁

Resolution: delete codes 404, 405, 461-467

Section: 8 "Transactions", A.2

Issue: the 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: you need a transaction identifier to use when reporting a syntax error when the identifier itself 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: the final paragraph has the wrong text for error code 442 🙈

Resolution: change it 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 and 2404, which are indirectly referenced). It's also unclear whether the source or destination UDP port gets prepended in the calculation 🦋

Resolution: change the second-last sentence of the second paragraph of 10.2 to specify the destination port, in consistency with IPSEC. In Annex B.2, change the lower count for the production AuthData from 32 to 24.

Section: 11.2 "Cold Start"

Issue: the last sentence of the first paragraph got accidentally modified, and now it duplicates material in 11.3 🌀

Resolution: restore the 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: in the second paragraph, the wrong MG is specified as the one to use after failover 🙃

Resolution: change the fourth sentence to refer to "secondary MG" rather than "primary MG".

Section: 12.1.2 "Properties"

Issue: as indicated in 6.2.4, Properties show up in other descriptors besides LocalControl and TerminationState, and the text doesn't say so 🌈

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: the note says a default duration should be specified for BR signals. This also applies to TO signals 💜

Resolution: add TO signals to the note.

Section: 12.2 "Guidelines to defining Properties, Statistics and Parameters to Events and Signals", B.2

Issue: the text says statistics can have the sub-list data type, but the ABNF doesn't support that 😬

Resolution: qualify the sublist type by adding the note: "(not supported for statistics)".

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 a message relating to the same context might switch between binary and text encoding, 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: the ASN.1 is pretty sloppy 😭 In production EventBufferControl, the values "off" and "lockstep" shouldn't be capitalized. 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: the syntax for PropertyParm doesn't support sub-lists, which are parameters that support multiple values at the same time 🫶

Resolution: add a third choice to extrainfo in PropertyParm as follows:

            extraInfo   CHOICE
        {
                relation        Relation,
                range           BOOLEAN,
                sublist         BOOLEAN
        } OPTIONAL

okay so the first bit is the ASN.1 fix, and you need to add an appropriate note to the comments right above it 💅

Issue: LocalControlDescriptor still has reserve instead of reserveValue and reserveGroup 🎀 Resolution: swap reserve for two separate Booleans, reserveValue and reserveGroup ✨

Issue: EventBufferDescriptor is wrongly drawn as a SEQUENCE OF ObservedEvent 🙈 Resolution: replace it with these productions:

EventBufferDescriptor ::= SEQUENCE OF EventSpec

EventSpec ::= SEQUENCE {
     pkgdName                PkgdName,
     streamID                StreamID OPTIONAL,
     evParList               SEQUENCE OF EventParameter }

Issue: the assigned object identifier is missing, even though it's usually there by convention 🧚 Resolution: add an object identifier line to the message header with this content: "itu-t recommendation h 248 media-gateway-control(0)". Then delete the version field, since the OID makes it redundant 🫶

Issue: the T.35 country code in the H221NonStandard production doesn't have the right structure 😭 Resolution: fix it 💖

Annex B.2, ABNF Syntax

Issue: the syntax for parmValue and VALUE together makes range parsing ambiguous 💀 Sub-lists and sets of alternative values also share the same syntax, which opens the door to more ambiguity 🌀 Resolution: replace the alternativeValue production with this:

alternativeValue = ( VALUE
     / LSBRKT VALUE *(COMMA VALUE) RSBRKT     ; sub-list
     / LBRKT VALUE *(COMMA VALUE) RBRKT       ; alternatives
     / LSBRKT VALUE COLON VALUE RSBRKT )      ; range

Issue: eventBufferDescriptor content was mistakenly shown as a sequence of observedEvent 🥀 Resolution: replace the eventBufferDescriptor production with these:

eventBufferDescriptor = EventBufferToken LBRKT [ eventSpec
   *( COMMA eventSpec ) ] RBRKT

eventSpec = pkgdName [ LBRKT  eventSpecParameter
                       *( COMMA eventSpecParameter ) RBRKT ]

eventSpecParameter = ( eventStream / eventOther )

Issue: there's an error in the digitMapDescriptor syntax, because the value is supposed to be optional 🍓 Resolution: change the production to:

digitMapDescriptor = DigitMapToken EQUAL digitMapName
             [ LBRKT digitMapValue RBRKT ]

Issue: VersionToken isn't defined anywhere 🌸 Resolution: add this ABNF:

VersionToken =  ("Version" / "V")

Issue: DiscardToken isn't used 🫠 Resolution: delete the production 🗑️

Annex C

Issue: nobody says how sub-octet fields are aligned inside the octet 🙃 Resolution: add a note that fields of sub-octet length are placed in the low-order bits of the octet 🦋

Issue: the direction of flow is split up by outgoing (Remote descriptor) and incoming (Local descriptor). But forward and backward properties will never sit in the same descriptor, so we only need one set of properties that works for both directions 🔥 Resolution: replace them with a single set of properties 👑

Issue: there are assorted problems. Some parameter specs don't match the relevant standards, some parameters aren't used, the ATM Forum and ITU-T usages aren't clearly separated, and some references are missing 😵‍💫 Resolution: fix them all 💅

Annex C.8, "ATM AAL1"

Issue: the length of GIT is wrong 😩 Resolution: this is an ITU-T procedural problem, so SG 16 will deal with it. The probable fix is to allow 29 octets, even though the relevant form only needs four octets 🧩

Annex C.9, "Bearer Capabilities"

Issue: ITC refers to a note 2 that doesn't exist 👻 Resolution: delete the reference 🧹

Issue: it isn't clear that the Q.931 Bearer Capability IE is being used, not the Low Layer Compatibility IE 🤷‍♀️ Resolution: specify that the values are the ones valid for the Bearer Capability IE 🎀

Annex D.1, "Transport over IP/UDP using Application Level Framing"

Issue: even when there's a handoff or failover, the originating MGC still needs confirmation that its command was received 😤 Resolution: in the last sentence of the first paragraph, delete the excepting clause so the sentence reads: "Responses must be sent to the address and port from which the corresponding commands were sent." 🫶

Annex D.1.1, "Providing At-Most-Once Functionality"

Issue: the last sentence of the second paragraph points to a procedure in 8.2.3, but it should point to the UDP-specific procedures 🧭 Resolution: add a reference to D.1.4 🔗

Annex D.1.3, "Repeating Requests, Responses and Acknowledgements"

Issue: exponential backoff in the face of congestion should be mandatory 🚦 Resolution: in the paragraph just before the note that starts "The specification purposely avoids specifying any value for the retransmission timers...", add this 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." 💥

Also, in the paragraph in the middle of the note that begins "After any retransmission ...", capitalize SHOULD so it really stands out, since the steps after it matter a lot 📣

Issue: the last paragraph is vague about which ServiceChangeReason to use when recovering from loss of contact. It has to be "Disconnected" every time 😬 Resolution: change the two sentences after the phrase "_ and it begins its recovery process" so they read: "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." 🌈

Annex D.1.4, "Provisional responses"

Issue: the last sentence of the first paragraph talks about when to send the Transaction Pending response. With UDP/ALF, the originator can repeat a transaction if it hasn't received an acknowledgement, and the right response to a duplicate that's still being processed is Transaction Pending 🔁 Resolution: add this sentence: "They SHOULD send this response if they receive a repetition of a transaction that is still being executed." 🦋

Issue: in the second paragraph, the transaction originator may never have gotten the TransactionPending responses because they were lost. So it might not know the responder wants an immediate acknowledgement of the TransactionReply 🫠 Resolution: add an optional field to TransactionReply so the responder can say whether an immediate ACK is required. Also add text saying that when the responder has sent a provisional response, it shall also set that indicator in the final transaction reply to show an immediate acknowledgement is required ✨

Annex E, "Basic Packages"

Issue: the package numbering doesn't follow the order they're presented in 🔢 Resolution: renumber the packages so they follow the order of numbering 🍰

Annex E.2.1, "Base Root Package -- Properties"

Issue: the descriptor these properties live in isn't specified 🕵️‍♀️ Resolution: in each case, say that the property is defined in the TerminationState descriptor 💜

Annex E.6.2, "DTMF detection Package -- Events"

Issue: "Long duration event modifier" is shown as "L" in the DigitString parameter, but it should be "Z" 💅 Resolution: replace it with "Z" 🫶

Annex E.9.2, "Analog Line Supervision Package -- Events"

Issue: the stated hook state reporting behaviour has a race condition, so the same transition could get 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, the one saying the event is always reported if the hook state has already been reached 🌸

The EventsDescriptor parameter works like this:

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 works like this:

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)

Annex E.10.3, "Basic Continuity Package -- Signals"

Issue: the rsp signal should keep going until the MGC tells the MG to stop applying it 🔄 Resolution: change the signal type from Timeout to ON/OFF 🎚️

Annex E.10.5, "Basic Continuity Package -- Procedures"

Issue: the wording of the condition for generating a cmp event with "success" doesn't cover the case where the test also needs the tone to be removed successfully 🧐 Resolution: in the second paragraph of E.10.5 (about test initiation), add the words "and any other required conditions are satisfied" to the second sentence, as part of the condition that success is reported under. Then replace the third paragraph (about test response) with this 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." 📞

Appendix A.1.2, "Example -- Collecting Originator Digits and Initiating Termination"

Issue: Step 3 uses the now-obsolete DS0 package for echo cancellation 🕰️ Resolution: replace it with echo cancellation via the TDM package 🔁

Issue: Step 20 doesn't show a returned TerminationStateDescriptor. It also includes the wrong statement that an RTP termination doesn't support events and signals, and it leaves out several other descriptors 🙈 Resolution: delete the sentence with the wrong statement. Then add this to the Media Descriptor, right before the line "Stream = 1_":

TerminationState { ServiceStates = InService, EventBufferControl = OFF },

Then add lines for the Events, Signals, and DigitMap descriptors after the Media descriptor:

Events, Signals, DigitMap,

4. Security Considerations 🛡️

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

5. References 📚

Okay so bestie, this is where the document lists its sources, and I need you to know these are all the receipts. 🧾✨

5.1. Normative References

Hmm, wait, the original doesn't have a 5.1 or 5.2 split, so I'm not adding one. Here's the list as it is:

  • [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 is basically a big thank-you 💖 to everyone on the Megaco list and the H.248 faithful in ITU-T Study Group 16 who actually sat down and read the Megaco/H.248 document with care and attention. Like, the real ones. 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

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. 🍓

📦 where this page comes from