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

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 10 Mar 2000 15:24:34 -0600

My responses below.  Consider them attempts at clarification.  Final
resolution undoubtedly requires further discussion.

> -----Original Message-----
> From: Flemming Andreasen [SMTP:[email-masked]]
> Sent: Tuesday, March 07, 2000 8:28 PM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]; Megaco
> Subject:      Comments on draft-ietf-megaco-protocol-07
>
> 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.
        [[TomT]]  My understanding is that for every parameter that occurs
at least once in the set of responses, the audit will return the complete
list of values taken on by that parameter over all of the responses being
summarized.  Others may have a different view, in which case clarifying text
is probably needed.

> 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 ?
        [[TomT]]  I suppose.  The error comes from my thinking of loopback
in terms of a wire, when actually it probably requires the assignment of a
DSP resource.  I expect loopback with an arbitrary payload type is easier to
provide than sending or receiving an arbitrary payload type.

> 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.
        [[TomT]]  Maybe Michael Brown has commented -- I know that this was
a deliberate rather than accidental choice when he and Chip were working out
the details of the language.  You do get an anomalous transient condition
where buffering has been deactivated but the buffer has content, but in fact
the buffer can be cleared in a single transaction.  Brian mentioned the need
to clear a buffer sometimes, but you can do that by including a Modify with
an empty Event Descriptor within a transaction, preceding the command
containing the new Event Descriptor.

> 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.
        [[TomT]]  Your suggestion is a possibility.  Another is to assume
that the failures you're really interested in are covered by the
Generic/Cause event (which IMHO belongs in Network rather than Generic, but
that's another story).  We'll have to see what other people have to say
about this.

> 6) 7.1.11, last bullet list and sentence before that seems redundant
> with the KeepActive flag and could/should consequently be removed.
        [[TomT]]  It's talking about sequential signal lists rather than
individual signals.  Lists need special treatment.

> 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.
        [[TomT]]  Agreed that the grammar may continue past the dot, but
until you get that far you have an ambiguous situation -- you don't know how
many events will be mapped into the dot.  The sentence is correct AFAIK.

> 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.
        [[TomT]]  Same problem as with the previous remark -- you don't know
when you've gone past the dot until it's too late.  If there is a timer both
before and after the dot, a timer after the dot never gets used.  It may be
better just to say that, I suppose, leaving it up to the MGC to set a timer
before the dot if it wants.

> 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.
        [[TomT]]  I assume you mean the last sentence of the paragraph.  You
will reach this case only if all of the alternatives specifying a
long-duration event at this point have been discarded.  Thus duration
becomes irrelevant, but only after it has been taken into account in the
cases where it mattered.

> 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.
        [[TomT]]  Good catch.  This really is an error.  We should change
that to "If exactly one candidate remains and it is fully matched, ..."

> 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.
        [[TomT]]  I had it that way in the first place (with the triggering
event distinguished by being placed in an "extra event" parameter) and
consensus was to change it to what it is now.  Have to overrule you on this
one unless you get more support.  I'm also not clear how you get duplicate
processing -- the situation is logically equivalent to the triggering event
(a non-matching digit) happening just after the digit completion event has
been notified.

> 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.
        [[TomT]]  This paragraph gives the interpretation of e.g. the "dd/*"
event specification.  Using the example digit map which immediately follows,
a dialled "1" will be reported immediately and also accumulated into the
digit map.  Of course, if EventBufferControl is set to LockStep, the digit
map will never complete because a new Event Descriptor will be loaded before
completion can be reported.  (There is a corner case with a dialled "0" and
short timer expiry before the new Event descriptor is loaded, but let's not
go into that.)

> 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.
        [[TomT]]  Opinions?  I don't have any.

> 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.
        [[TomT]]  Actually, 6.2.4 is probably in error, since this is the
most recently modified section.  Other opinions?

> 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).
        [[TomT]]  Why can't the sentence mean what it says?  A digit map is
a name and a value.  This paragraph doesn't say that the same digit map is
reported multiple times, which I think is what you are implying.

> 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.
        [[TomT]]  You were overruled by prevailing consensus.  Basically the
view is that the MGC is responsible for controlling the state of
terminations, aside from in-service/test/out-of-service.  If it really wants
to clear all contexts it has the tools to do that.

> 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.
        [[TomT]]  You have a point.

> 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
        [[TomT]]  You're right.

> 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.
        [[TomT]]  No consensus on this.

> 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"
        [[TomT]]  I think you're right.

> 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.
        [[TomT]]  Makes sense to me.

> 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.
        [[TomT]]  Sorry, what's the difference between what you propose and
what's there now?

> 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").
        [[TomT]]  Or perhaps both references, since you need both to tell
the whole story.

> 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.
        [[TomT]]  Seems reasonable.  Comments?

> 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.
        [[TomT]]  I like this -- since the alternatives are mutually
exclusive it would be just one parameter.  Other views?

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

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 10 Mar 2000 19:10:06 -0500

Tom

Thanks for the responses. Rather than continuing all of these in a single
e-mail, let me break out some of them as indicated below.

> summarized.  Others may have a different view, in which case clarifying text

An example would probably clear this.

> containing the new Event Descriptor.

I've gotten comments from John Segers, but we didn't seem to get anywhere.
Although I disagree, we can leave 4) as is since we can always define a new
EventBufferControl value.

> that's another story).  We'll have to see what other people have to say

I suppose you could if we clarified the description to state that signal
failures would be covered as well.

> individual signals.  Lists need special treatment.

Well, the special treatment seems to be exactly what KeepActive does, but no big
deal.

> short timer expiry before the new Event descriptor is loaded, but let's not

Separate e-mail on 7.1.14.

> reported multiple times, which I think is what you are implying.

See separate e-mail

> to clear all contexts it has the tools to do that.

See separate e-mail

Certainly not on the mailing list. There were only a few mails exchanged on this
issue, in particular by Chip, Brian, and myself. I never got a
response/resolution to the last one I sent out.

>         [[TomT]]  No consensus on this.

So it's basically undefined.

>         [[TomT]]  Sorry, what's the difference between what you propose and

See separate e-mail

> > specification for this needs to be added.

Didn't see a response here.

> > *must* be issued in such cases.

Didn't see a response here.

--
Flemming Andreasen
Cisco Systems