Subject: Comments on v12

From: Harpreet Singh Anand <[email-masked]>
Date: Thu, 4 Nov 1999 13:15:24 +0530

Hello Brian, John,

Please find comments on the v12 draft.

1. Section 6.2.1: "An MGC can only release/modify terminations and the resources
that the termination represents
which it has previously seized via e.g. the Add command."

This statement seems to imply that an MGC can modify termination only after they
have been seized using the Add command. Does that mean that an MGC can not
modify terminations in a NULL context ?

2. Section 6.2.2: "A wildcarding mechanism using two types of wildcards can be
used with TerminationIDs. The
two wildcards are ALL and CHOOSE. The former is used to address multiple
Terminations at once, while the latter is used to indicate to a media gateway
that it must select a Termination satisfying the partially specified
TerminationID."

In the text encoding, it is possible to let the MG choose a termination Id by
using $, but it is not possible to choose from a partially specified
termination, that is it is not possible to tell MG to choose any termination
starting with say R12/C2/. The same is possible in the binary encoding.

I think both the encoding should support the same set of features and hence $
should be allowed in the termination id to be able to describe partially
specified terminationid as R12/C2/$.

3. Section 11.1 "ServiceChange may only be applied to the Root by the Master
MGC."

Why such a restriction is there ? Does this mean that if a ServiceChange is
applied to the ROOT of one Virtual MG, then it gets applied to all virtual MGs ?

Consider a scenario where a physical MG is decomposed into 3 virtual MGs being
controlled by three different MGCs. If one of the MGC (which is not the master
MGC) wants to handoff the virtual MG that it is controlling to another MGC, then
it should be able to send the SerivceChange on the Root termination to the
specific virtual MG that it is controlling. Why should only master MGc be
allowed to send ServiceChange on Root ?

4. Annex B:  ABNF sepcification for digitMapDescriptor:

digitMapDescriptor = DigitMapToken EQUAL digitMapName ( LBRKT digitMapValue
RBRKT )

should be

digitMapDescriptor = DigitMapToken EQUAL digitMapName [ LBRKT digitMapValue
RBRKT ]

5. Annex D.1.2: "MGs can simply detect duplicate transactions by looking at the
transaction identifier only."
This line needs to be rephrased. Both MG and MGC can detect a duplicate
transaction by looking at a combination of mId and TransactionId as
TransactionIds are unique wrt to the sender (refer section 8.1.1).

6. Annex D.1.4: "The root termination has a property
(ProvisionalResponseTimerValue), which can be
set to the requested maximum number of milliseconds between receipt of a command
and
transmission of the TransactionPending response."

How is "ProvisionalResponseTimerValue" different from "normalMGExecutionTime"
(as defined in section 8.2.3) ? Shouldn't the timer value for sending
TransactionPending message be derived from normalMgExecutionTime ?

7. Annex D.1.4: "In order to account for the possibility of an undetected or
in-progress "failover", we modify the classic algorithm so that if the Media
Gateway receives a
valid ServiceChange message announcing a failover, it will start transmitting
outstanding
commands to that new MGC."

This is also valid for MGC, that is, if MGC sees a ServiceChange with
"failover", then it should reset the retransmission count and send the
outstanding commands to the new MG.

Also in the case of ServiceChange with ServiceChangeMethod as "Handoff", the
retransmission count should be set to zero and the pending transactions and
transaction replies have to be sent to the new MGC.

8. Annex D.1.4: "It is however important that the maximum delay of
retransmissions be bounded. Prior to any
retransmission, it is checked that the time elapsed since the sending of the
initial datagram is no
greater than T-MAX. If more than T-MAX time has elapsed, the MG concludes that
the MGC has
failed, and it begins its recovery process. The value T-MAX is related to the
LONG-TIMER value:
the LONG-TIMER value is obtained by adding to T-MAX the maximum propagation
delay in the
network."

I believe this works the other way also, that is, MGC also checks elapsed time
against T-MAX.

9. The positioning of Events descriptor and Signals Descriptor is not clear. Are
they part of the Stream Descriptor ? I believe they are not, in which case the
text in section 7.1.6 needs to be changed.

"A Stream descriptor specifies the parameters of a single bi-directional stream.
These parameters
are structured into five descriptors; one that contains termination properties
specific to a stream,
one each for local and remote flows, a signals descriptor and an events
descriptor."

10. Meaning of optional command: This issue has been raised earlier also on the
mailing list but I am not sure of the result.

Does the optional command mean:

"Commands may be marked as “Optional” which can override this behavior – if an
optional command results in an error, subsequent commands in the Transaction
will be executed." (as specified in section 8)
OR
"If a command is marked as optional, the MG has the choice of executing it or
not, and if it does
execute it, it returns the Response, or Error." (as specified in section 8.2.2)
OR
Both ?

If the meaning is both then I suggest both the interpretations should be given
in section 8 itself.

11. Section 12.1.3: "ObservedEventDescriptor Parameters:
Parameters returned to the MGC in the Notify, and found in the
ObservedEventDescriptor."

Should be:

ObservedEventDescriptor Parameters:
Parameters returned to the MGC in the Notify, Audit Value and Audit
Capabilities, and found in the
ObservedEventDescriptor.

12. Section 12.1.2: "Characteristics: Read / Write or both."
What is the significance of having a write only property ?

13. Section 12.1.3 and 12.1.4:  Instead of referring to section 12.1.1, the
reference should be 12.2

14. Section 12.2: "Guidelines to defining Parameters to Properties, Events,
Signals, and Statistics."
Can we have parameters to Properties and Statistics ? Section 12.1.2 and 12.1.5
do not not mention any parameters to properties and statistics.

15. Section 7.2.8: - Failover should be added to the list of possible values for
ServiceChange Method. It would also be helpful, if for each ServiceChangeMethod
it is explained whether it is possible to use it from MGC or MG or both.

Regards,
Harpreet

_________________________________
Harpreet Singh Anand
Ficon Technology
E-mail :  mailto:[email-masked]
Web    :  http://www.ficon-tech.com