As per Relevance of the word following, we have this rfc below:
Network Working Group T.
Request for Comments: 2886 Nortel
Category: Standards Track August 2000
Megaco
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
1.
This document records the errors found in the Megaco/H.248
document [2], along with the changes proposed in the text of
document to resolve them
2. Conventions used in this
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC-2119 [1].
3.
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
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,
termination Tb with properties p2=c, p3=d a
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
and reinstated when termination returns to Null. Contradicts
text in 7.2.3.
Resolution: Rewrite the first paragraph from the third
onward, to read: "Most properties have default values, which
explicitly defined in this standard or in a package (see Section 12)
or set by provisioning. If not provisioned otherwise,
descriptors except for TerminationState and LocalControl default
empty/"no value" when a termination is first created or is
to the null context. The default contents of the two exceptions
described in sections 7.1.5 and 7.1.7."
Issue: DigitMap entry in table makes explicit reference to
tones, but is also intended to apply to other in-band
systems
Resolution: Change existing text to new one as follows: "
patterns against which sequences of a specified set of events are
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
paragraph, listing what is valid for Root. Add "statistics" to
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
the MGC
Proposed resolution: In section 7.1, add the following text after
sentence: "Descriptors may be returned as output from a command.":
"In any such return of descriptor contents, an empty descriptor
represented by its name unaccompanied by any list."
In the ASN.1, add the following choice to the
production
"emptyDescriptors AuditDescriptor,"
In the ABNF, add the choice auditItem to the
auditReturnParameter
Section: 7.1.1 "Specifying Parameters
----------
Issue: Third paragraph (discussing unspecified parameters): not
which parameters are mandatory
Resolution: Replace the first two sentences (each beginning with
word "unspecified") with the following text: "If a
descriptor other than the Audit descriptor is unspecified (i.e
entirely absent) from a command, the previous values set in
descriptor for that termination, if any, are retained. A
Audit descriptor is equivalent to an empty Audit descriptor.
behaviour of the MG with respect to unspecified parameters within
descriptor varies with the descriptor concerned, as indicated
succeeding sections."
Section: 7.1.6 "Stream Descriptor", ABNF (Annex B.2)
----------
Issue: Text indicates use of "true" and "false" values while
uses "on" and "off
Resolution: Add comment in B.2 that "true" in text corresponds
"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
item beginning: "If the Mode property of the LocalControl
is RecvOnly or SendRecv,...", could also have DSP involvement in
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
implied in the EventsDescriptor, EventDM is used to carry either
name or the value of the associated digit map. See section 7.1.14."
Issue: Not clear whether events trigger side effects (e.g.
termination) at time of detection, at time of processing (whether
not in active Events Descriptor) or at time of notification. Also
the third paragraph of the section fails to mention these
effects and limits MG action to notification
Resolution: Modify the third paragraph of the section, so that
reads: "When an event (either newly detected or buffered)
processed against the contents of an active Events descriptor
found to be present in that descriptor ("recognized"), the
action of the MG is to send a Notify command to the MG.
may be deferred if the event is absorbed into the current dial
of an active digit map (see section 7.1.14). Any other action is
further study. Moreover, event recognition may cause
active signals to stop, or may cause the current Events and/
Signals descriptor to be replaced, as described at the end of
section."
Replace "detection" with "recognition" in the fourth paragraph
the end, so that it reads: "Normally, recognition of an event
cause any active signals to stop. When KeepActive is specified
the event, the MG shall not interrupt any signals active on
Termination on which the event is detected."
In the third-last paragraph, replace all three instances
"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
may result in an infinite loop. Also, the step excludes side
actions such as signal termination
Resolution: Modify step 2(a) to read: "If the event in the queue
in the events listed in the new EventsDescriptor, the MG acts on
event and removes it from the EventBuffer. The time stamp of
Notify shall be the time the event was actually detected. The
then waits for a new EventsDescriptor. While waiting for a
EventsDescriptor, any events detected which appear in the
EventsBufferDescriptor will be placed in the EventBuffer. When a
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
failures. It is not possible to use the signal completion event
monitor for signalling failures only, without also having to
successes
Proposed Resolution: In section 7.1.11, replace the current text
completion notification, beginning: "Finally, the optional
"notifyCompletion" ..." and continuing to the end of the
with the following text
"Finally, the optional parameter "notifyCompletion" allows a MGC
indicate the circumstances under which it wishes to be notified
the signal finishes playout. The possible cases are that the
timed out, that it was interrupted by an event, that it was
when a Signals descriptor was replaced, or that it stopped or
started for other reasons. If "notifyCompletion" is absent
notification is generated in the "other reasons" case only.
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
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
(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 "
formal syntax of the digit map [...]")
7.1.14.4 DigitMap completion event (before the paragraph starting "
digit map is active while the events descriptor [...]")
7.1.14.5 DigitMap procedures (before the sentence "
completion, successive events shall be processed [...]",
the numbered list
7.1.14.6 DigitMap activation (after the numbered list
7.1.14.7 Interaction of DigitMap and event processing (before
next paragraph, starting "While the digit map is activated, [...]")
7.1.14.8 Wildcards (before the the next paragraph, starting "
that if a package contains [...]")
7.1.14.9 Example (before the example
Issue: incorrect statements regarding the interaction of the
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
consequence of the third timing rule above, inter-event timing
matching a terminal dot symbol uses the short timer by default."
the next paragraph, the third sentence, which begins: "A
specifier following a dot ...", should be deleted
Issue: Step 5 in second numbered list understates conditions
digit map completion when single candidate remains
Resolution: Add the words "and it has been fully matched" to
existing sentence. Also remove the parenthetical remark: "...
(because the candidate set still contains more than one
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
side effects (e.g. signal termination).
Resolution: Modify the final sentence of the paragraph
procedural step 6 to read as follows: "Normal event behaviour (e.g
stopping of signals unless the digit completion event has
KeepActive flag enabled) continues to apply for each such
detected, except
. the events in the package containing the specified digit
completion event other than the completion event itself are
individually notified,
. an event which triggers a "partial match" completion is
recognized and therefore has no side effects until
following the recognition of the digit map completion event."
Issue: the last paragraph before the example is misleading if
package containing the digit map completion event is different
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
contains the digit events themselves, this form of
specification ...".
Section: 7.1.18 "Topology Descriptor
----------
Issue: Third bullet attached to third para: says loopback achieved
manipulating TerminationMode, which no longer has that name
Resolution: Delete the clause "; loopbacks are created by setting
TerminationMode
Section: 7.2
----------
Issue: The order in which descriptors are processed within a
matters, but is not clear. Moreover, it is fixed in the ASN.1
variable in the ABNF
Resolution: Add text stating that descriptors are processed in
order in which they are provided. Change ASN.1 in Annex A.2 to
the MGC to specify ordering
Taylor Standards Track [Page 7]
RFC 2886 Megaco Errata August 2000
AmmRequest ::=
{
terminationID TerminationIDList
descriptors SEQUENCE OF AmmDescriptor
-- At most one descriptor of each type (see AmmDescriptor
-- allowed in the
...
}
AmmDescriptor ::=
{
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
command
Resolution: add this qualification to the second sentence,
indicates that terminationId may be wildcarded
Section: 7.2.4 "Move
----------
Issue: cannot use the CHOOSE wildcard for terminationId of a
command
Resolution: add this qualification to the second sentence,
indicates that terminationId may be wildcarded
Section: 7.2.5 "AuditValue
----------
Issue: Not clear whether AuditValue of
reports events captured in current dial string of active digit map
Resolution: Add text to indicate that if a digit map is active
ObservedEventsDescriptor is specified the response to an
includes a digit map completion event which shows the current
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
Resolution: Add the following text: "EventBuffer returns the set
events and associated parameter values currently enabled in
EventBufferDescriptor."
Issue: not clear whether wildcarded context includes the
context
Resolution: add statement that ALL as a contextID does not
the null context
Issue: the text of 7.2.5 allows retrieval of multiple digit maps
one AuditValue command if the terminationId is ALL. Moreover
earlier text in the Annex anticipates that multiple instances of
descriptor may be returned. The comment in front of
auditReturnParameter in Annex B.2 contradicts this text. Note
Annex A has no restriction on the number of instances of
descriptor in either a command or a response
Proposed Resolution: delete the"at-most-once" comment preceding
production auditReturnParameter
Issue: Does not indicate how an audit of digit maps returns
digit maps
Resolution: Change syntax of DigitMapDescriptor to allow return
unnamed digit maps as follows
digitMapDescriptor = DigitMapToken
( (LBRKT digitMapValue RBRKT
/ (digitMapname [ LBRKT digitMapValue RBRKT ])
)
DigitMapDescriptor ::= SEQUENCE {
digitMapName DigitMapName OPTIONAL
digitMapValue DigitMapValue OPTIONAL }
Issue: the text in section 7.2.5 mentions that using an empty
descriptor with a wildcarded terminationId is a way to get a list
the terminations in the context. Annex A provides the
that the auditReply may be a contextAuditResult of
terminationIdList, and Annex B allows for an auditReply containing
contextTerminationAudit which in turn presents a terminationIdList
The connection between the text in 7.2.5 and these special forms
audit result is not clear. Moreover, a note at the beginning
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
the sentence "This may be useful to get a list of TerminationIDs
used with wildcard.": "Annexes A and B provide a special syntax
presenting such a list in condensed form, such that the
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,
an exception on the length of type TerminationIdList when used
contextAuditResult
Section: 7.2.6 "AuditCapabilities
----------
Issue: Fails to indicate what AuditCapabilities
EventBufferDescriptor
Resolution: Add the following text: "EventBuffer returns the
information as Events."
Issue: Inconsistency regarding permissibility of DigitMap or
as capability audit items
Resolution: Add comment to B.2 "auditItem" production indicating
DigitMap and Packages are not allowed in the
command
Section: 7.2.8 "ServiceChange
----------
Issue: In point 1) describing the Graceful ServiceChange method,
scope of the recommendation against new connections is unclear
Resolution: at the end of the first sentence, add the phrase "on
termination(s) affected by the ServiceChange command".
Issue: the explanatory string associated with ServiceChangeReason
optional in the syntax, but not in the text
Resolution: add "optional" before "explanatory string" in
explanation of the ServiceChangeReason" parameter
Issue: Paragraph beginning "A ServiceChange Command specifying
Root..." immediately following the description of
Descriptor parameters erroneously states that the response to
ServiceChange command terminates the registration process. This
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
registration process, except when the MGC has returned an
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
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
shall as far as possible restore the state which prevailed prior
the attempted execution of the command before continuing
transaction processing."
Section: 8.1.1 "Transaction Identifiers
----------
Issue: need a transaction identifier to use when reporting a
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
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
digits (per RFCs 2403, 2404 which are indirectly referenced). It
also unclear whether it is the source or destination UDP port
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
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
establish a control relationship with any MGC, it shall wait a
amount of time as described in Section 9.2 and then start
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
failover
Resolution: Change fourth sentence to refer to "secondary MG"
than "primary MG".
Section: 12.1.2 "Properties
----------
Issue: As indicated in 6.2.4, Properties occur in other
besides LocalControl and TerminationState
Resolution: after the sentence mentioning TerminationState,
another sentence: "Although these are the most common cases, it
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
signals. This also applies to TO signals
Resolution: Add TO signals to note
Section: 12.2 "Guidelines to defining Properties, Statistics
Parameters to Events and Signals", B.2
----------
Issue: Text indicates that statistics can have the sub-list
type, but ABNF does not support that
Resolution: qualify the sublist type by adding the note: "(
supported for statistics)".
Taylor Standards Track [Page 12]
RFC 2886 Megaco Errata August 2000
Section: Annex A.1, ASN.1
----------
Issue: the ASN.1 uses the values 0x0, 0xFFFFFFFE, and 0xFFFFFFFF
the NULL context, a wildcard CHOOSE of context, and a wildcard ALL
context respectively. Because of the possibility of a switch
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
B.2 indicating that these values are reserved
Section: Annex A.2, ASN.1
----------
Issue: sloppy ASN.1 -- in production EventBufferControl the
"off" and "lockstep" should not be capitalized, and IA5STRING
production NonStandardIdentifier should be IA5String.
TransactionID and TransactionId are used. A number of
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
follows
extraInfo
{
relation Relation
range BOOLEAN
sublist
}
and add an appropriate note to the preceding comments
Issue: LocalControlDescriptor still contains reserve rather
reserveValue and reserveGroup
Resolution: Replace reserve with separate reserveValue
reserveGroup Booleans
Issue: EventBufferDescriptor is incorrectly portrayed as a
OF ObservedEvent
Resolution: replace with the following productions
Taylor Standards Track [Page 13]
RFC 2886 Megaco Errata August 2000
EventBufferDescriptor ::= SEQUENCE OF
EventSpec ::= SEQUENCE {
pkgdName PkgdName
streamID StreamID OPTIONAL
evParList SEQUENCE OF EventParameter }
Issue: Assigned object identifier missing. It is usually present
a matter of convention
Resolution: Add object identifier line in the message header
content
"itu-t recommendation h 248 media-gateway-control(0)" Delete
version field, which this makes redundant
Issue: the T.35 country code in the H221NonStandard production
not have the right structure
Resolution: fix it
Section: Annex B.2, ABNF
----------
Issue: Syntax for parmValue and VALUE together make parsing of
ambiguous. Furthermore, sub-lists and sets of alternative
have the same syntax, introducing possible
Resolution: Replace production alternativeValue by the following
"alternativeValue = (
/ LSBRKT VALUE *(COMMA VALUE) RSBRKT ; sub-
/ LBRKT VALUE *(COMMA VALUE) RBRKT ;
/ LSBRKT VALUE COLON VALUE RSBRKT ) ; range
Issue: EventBufferDescriptor content mistakenly shown as a
of observedEvent
Resolution: replace the production for eventBufferDescriptor with
following productions
eventBufferDescriptor = EventBufferToken LBRKT [
*( COMMA eventSpec ) ]
eventSpec = pkgdName [ LBRKT
*( COMMA eventSpecParameter ) RBRKT ]
eventSpecParameter = ( eventStream / eventOther )
Issue: Error in syntax for digitMapDescriptor: value meant to
optional
Taylor Standards Track [Page 14]
RFC 2886 Megaco Errata August 2000
Resolution: Change production
digitMapDescriptor = DigitMapToken EQUAL
[ LBRKT digitMapValue RBRKT ]
Issue: VersionToken not defined
Resolution: Add ABNF: VersionToken = ("Version" / "V")
Issue: DiscardToken not used
Resolution: Delete production
Section: Annex
----------
Issue: alignment of sub-octet fields within the octet is
indicated
Resolution: add note that fields of sub-octet length are placed
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 (
descriptor) and incoming (Local descriptor). Since forward
backward properties will not both reside in the same descriptor,
only the one set of properties applicable to both directions
Resolution: replace with a single set of properties
Issue: miscellaneous problems of parameter
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
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
Layer Compatibility IE is being used
Resolution: Specify that values are those valid for Bearer
Section: Annex D.1 "Transport over IP/UDP using Application
Framing
----------
Issue: Even in the case of handoff or failover, the originating
needs confirmation that its command was received
Resolution: In the last sentence of the first paragraph, delete
excepting clause, so that the sentence reads: "Responses must be
to the address and port from which the corresponding commands
sent."
Section: Annex D.1.1 "Providing At-Most-Once Functionality
----------
Issue: Second para last sentence provides a procedural reference
8.2.3. Should refer to UDP-specific procedures
Resolution: Add reference to D.1.4.
Section: Annex D.1.3 "Repeating Requests, Responses
Acknowledgements
----------
Issue: Make exponential backoff in the face of congestion mandatory
Resolution: To the paragraph just before the note, which begins "
specification purposely avoids specifying any value for
retransmission timers...", add the following sentence
"Implementations SHALL ensure that the algorithm used to
retransmission timing performs an exponentially increasing backoff
the retransmission timeout for each retransmission or
after the first one."
In the paragraph in the middle of the note beginning "After
retransmission ...", capitalize the word SHOULD to emphasize
importance of the steps which follow
Issue: Last paragraph is equivocal about what ServiceChangeReason
use when recovering from loss of contact; it must always
"Disconnected".
Taylor Standards Track [Page 16]
RFC 2886 Megaco Errata August 2000
Resolution: Change the two sentences following the phrase "_ and
begins its recovery process" to read as follows: "The MG shall use
ServiceChange with ServiceChangeMethod set to disconnected so
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
Transaction Pending response. When UDP/ALF is in use, the
of a transaction may repeat it because it has not received
acknowledgement that the transaction was received. An
response to a duplicate transaction which is still being processed
to return Transaction Pending
Resolution: Add the sentence: "They SHOULD send this response if
receive a repetition of a transaction that is still being executed."
Issue: Second para: transaction originator may not have
TransactionPending response(s) because they were lost, and
therefore not know that responder is expecting
acknowledgement of the TransactionReply
Resolution: add an optional field to TransactionReply allowing
responder to indicate if an immediate ACK is required. Add text
the section indicating that when the responder has sent a
response, it shall also set the indicator in the final
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
specified
Resolution: in each case, indicate that the property is defined
the TerminationState descriptor
Section: Annex E.6.2 "DTMF detection Package -- Events
----------
Issue: "Long duration event modifier" is shown as "L" in
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
same transition could be reported twice
Resolution: add an optional EventsDescriptor parameter and
optional ObservedEvents parameter to each of the on-hook and off-
events. Delete the second sentence of the existing event
(which indicates that the event is always reported if the hook
has already been achieved).
The EventsDescriptor parameter is described as follows
Strict
ParameterID: strict (0x0001)
Type:
Possible values
"exact" means that only an actual hook state
to on-hook (off-hook) is to be
"state" means that the event is to be
either if the hook state transition is detected or if
hook state is already on-hook (off-hook). This is
default value if "strict" is unspecified
"failWrong" means that if the hook state is already
the transition would imply, the command fails and an
is reported [error code to be defined in the package].
The ObservedEvents parameter is described as follows
Initial
ParameterID: init (0x0002)
Type:
Possible values
true/"ON" means that the event was reported because
line was already on-hook (off-hook) when the
descriptor containing this event was
false/"OFF" means that the event represents an
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
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
tone
Resolution: In the second paragraph of E.10.5 (dealing with
initiation), add the words "and any other required conditions
satisfied" in the second sentence, as part of the condition
which success is reported. Replace the third paragraph (dealing
test response) with the following text
"When a MGC wants the MG to respond to a continuity test, it sends
command to the MG containing a signals descriptor with the
signal. Upon reception of a command with the rsp signal, the
either applies a loop-back or (for 2-wire circuits) awaits
of a continuity test tone. In the loop-back case, any
information shall be reflected back as outgoing information. In
2-wire case, any time the appropriate test tone is received,
appropriate response tone should be sent. The MGC will
when to remove the rsp signal."
Section: Appendix A.1.2 "Example -- Collecting Originator Digits
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
not support events and signals and fails to show a number of
descriptors
Resolution
Delete the sentence containing the erroneous statement
Add the following to the Media Descriptor preceding the line "
= 1_":
"TerminationState { ServiceStates = InService, EventBufferControl =
OFF },"
Add lines showing Events, Signals, and DigitMap
following the Media descriptor
"Events, Signals, DigitMap,"
Taylor Standards Track [Page 19]
RFC 2886 Megaco Errata August 2000
4. Security
This memo is a supplement to [2], which contains the
security section
5.
[1] Bradner, S., "The Internet Standards Process -- Revision 3",
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
Levels", BCP 14, RFC 2119, March 1997.
6.
This memo records the contributions of a number of people on
Megaco list and the H.248 faithful in ITU-T Study Group 16 who
the time to read the Megaco/H.248 document with care and attention
Thanks to all of them
7. Author's
Tom
Nortel
P.O. Box 3511, Station
Ottawa, Ontario, Canada K1Y 4P
Phone: +1 613 736 0961
EMail: taylor@nortelnetworks.
Taylor Standards Track [Page 20]
RFC 2886 Megaco Errata August 2000
8. Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Taylor Standards Track [Page 21]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
