Subject: Comments on draft-ietf-megaco-protocol-07

From: Flemming Andreasen <[email-masked]>
Date: Tue, 7 Mar 2000 20:27:51 -0500

Greetings

Below you will find some comments on draft-ietf-megaco-protocol-07.txt.

1) 6.2.2, second last paragraph:        It is still unclear to me what
these "UNION" responses look like, at least if something besides the
terminationID is returned. Please clarify.

2) 7.1.8, last bullet in second last bullet list:    Shouldn't the MG
also be prepared to receive media if Mode is loopback ?

3) 7.1.9, last sentence in the paragraph "When the MG receives a command
with a new EventsDescriptor, one or more events may have been buffered
in the EventBuffer i nthe MG. The value of EventBufferControl then
determines how the MG treats such buffered events" should be clarified
to indicate that the EventBufferControl referred to is the one for the
new command.

4) 7.1.9, the paragraph "If the MG receives a command instructing it to
set the value of EventBufferControl to Off, all events in the
EventBuffer SHALL be discarded" should be removed as there seems to be
no good reason for loosing those events.

5) 7.1.11, second paragraph:    The granularity of the signal completion
event defined in E.1.2 is too coarse. There is for example no way to be
informed of just failures (which would seem generally desirable) without
being more or less flooded by the other completion reasons as well (some
of which are more questionable). One simple way out of this is to extend
the definition of the signal completion event to include
EventsDescriptorParameters where the TerminationMethod(s) of interest
could be specified. Also, the term "notifyCompletion" is somewhat of a
misnomer.

6) 7.1.11, last bullet list and sentence before that seems redundant
with the KeepActive flag and could/should consequently be removed.

7) 7.1.14, last sentence in paragraph beginning with "The letter 'x' is
used as a wildcard..." specifies that "As a consequence of the thrid
timing rule above, inter-event timing while matching the dot symbol uses
the short timer by default." is incorrect. The grammar may continue past
the dot symbol implying the dot could only possibly produce a partial
match which furthermore implies that the short timer may not be the
right one to use. The sentence should simply be removed.

8) 7.1.14, next paragraph specifies that "A timer specified following a
dot specifies inter-event timing for all events matching the dot as well
as for subsequent events". It's unclear why the timer couldn't simply be
put in front of the dot and thereby be consistent with digit map timers
in general. In the absence of a compelling argument the sentence should
simply be removed.

9) 7.1.14, numbered list, item 4:    The second sentence and the last
sentence seem to contradict each other. While absence of long-duration
may prevent a match from occurring, existence of long-duration should
not. Consequently, the second sentence is what should be modified.

10) 7.1.14, numbered list, item 5 specifies that "If exactly one
candidate remains, a completion event is generated indicating an
unambiguous match". This seems to imply that even a partial match (as
long as there is only one) will result in a digit map completion event,
which of course is incorrect.

11) 7.1.14, numbered list, item 5:    It is entirely unclear why an
event triggering a partial match is not reported as part of the matched
string. In the absence of a compelling argument, the triggering event
should be included in the string as it otherwise may be processed twice,
which is hardly what the user had in mind.

12) 7.1.14, second last paragraph states that "Regardles of whether a
digit map is activated, this form of event specification will cause the
individual events to be reported to the MGC as they are detected". Some
clarification is requested here.

13) 7.1.17, first paragraph states that "Used with the AuditValue
command, the ObservedEventsDescriptor returns events in the event buffer
which have not been Notified". It should be clarified whether that
includes events that are being matched against a digit map or not.

14) 7.2.3, bullet list, first item states that [property values revert
to] "the default value, if specified for the property and not overriden
by provisioning". The provisioning part seems to contradict Section
6.2.4 and furthermore be redundant with the following bullet.
Consequently, the provisioning part in the first bullet should simply be
deleted.

15) 7.2.5, fourth paragraph states that "Digitmap requested in an
AuditValue command with TerminationID ALL returns all DigitMaps in the
gateway". Since digitmaps defined on specific terminations "shadow"
digit maps defined on the root termination, it would seem that digit
maps defined on root should be excluded here (unless the reporting
starts including the termination the digit map is defined on which seems
to be a more substantial change).

16) 7.2.8, Restart:    As I have stated before, it is a mistake that the
gateway is not defined to be in a clean and well-defined state when
"Restart" is issued. Consequently, I suggest that the sentence "the
Terminations are assumed to now not be associated with any Context" is
put back in this defintion again.

17) 7.2.8, paragraph beginning with "A ServiceChange Command
specifying..." states that "Acknowledgement of the ServiceChange Command
completes the registration process", however this seems to conflict with
the procedures specified later, where it is in fact determined by the
MGCId returned (if it's the same, registration completed). The sentence
should be modified accordingly.

18) 7.2.9, last paragraph specifies that "If a MG receives an action
which contains both a request to audit context attributes and a request
to manipulate those attributes, the response SHALL include the values of
the attributes after processing the manipulation request". While the
above behavior makes sense for a *command*, it does not for a action and
furthermore it is in conflict with the general command processing order
defined in Section 8. The sentence should be modified accordingly

19) 8:    It is still unclear whether commands are atomic or not. At the
very least this needs to be clarified as well as what effect a failed
command may have on a gateway/termination.

20a) 11.2, first paragraph, last sentence:    Editorial mistake (cf.
11.3) ? Sentence should be brought back to "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"

20b) 12.1.4, specifies that "Signals that would be played with
SignalType BR should have a default duration". The same should be
specified for signals with SignalType TO.

21) D.1, first paragraph, last sentence specifies that "Responses must
be sent to the address and port from which the corresponding commands
were sent except if the response to a handoff or failover, in which case
the procedures of 11.5 apply". While this may be reasonable for
clustered systems, it does not seem reasonable for handoff between
non-clustered systems. To enable reliable delivery of this message, the
response should still be sent to the source of the request, but
otherwise the procedures of 11.5 applies.

22) D.1.1, second paragraph, last line:    The reference to Section
8.2.3 should be replace with a reference to Section D.1.4, as this
section describes UDP specific requirements, where as 8.2.3 is transport
independent and consequently has looser specification language ("may").

23) D.1.4, first paragraph        The sentence "They should send this
response if they receive a repetition of a transaction that is still
being executed" has been deleted. The sentence should be added back in
again.

24) D.1.4, last paragraph specifies that "Upon receipt of of a final
response, an immediate confirmation shall be sent, and normal repetition
timers shall be used thereafter", however it is not specified how the
entity determines whether the final response needs to be confirmed
immediately or not (consider the case where the pending was lost). A
specification for this needs to be added.

25) D.1.5, last paragraph specifies that "When the MG establishes a new
control association, it can retransmit to the new MGC. Alternatively, a
MG may use a ServiceChange with ServiceChangeMethod equal to
disconnected to inform the new MGC that the MG lost one or more
transaction". In order to prevent duplicate transactions, it must be
required that transactions cannot be retransmitted T-MAX time after
their initial transmission. Consequently, a disconnected ServiceChange
*must* be issued in such cases.

26), E.1.2, Signal Completion:        See issue 5

27), E.9.2, onhook/offhook:            The text specifies that if
"onhook/ofhook" is requested while the phone is already onhook/offhook,
an onhook/offhook event will be generated. This behavior does not handle
glare properly and may consequently result in two onhook/offhook events
being generated for a single onhook/offhook transition. As part of glare
handling, it is furthermore important to enable a coupling between an
expected hook-state and the application of signals. One way of
accomplishing the above would simply be to define a couple of event
parameters for onhook and offhook:
A. No expected hook-state, just report next transition.
B. Expected hook-state, report if hook-state differs (the current text).

C. Expected hook-state must be met or command will fail.

28) E.10.2, specifies that "If the return tone is detected before the
signal times out, the cmp event shall be generated with the value...".
In practice, there may be a little more to the test (e.g. successful
removal of the tone again) so the success criteria should probably be a
little more general and simply refer to a successful test or not.

Regards

        Flemming

--
Flemming Andreasen
Cisco Systems