From: Prashant Jain <[email-masked]>
Date: Tue, 2 Nov 1999 09:49:44 +0530

hi brian, Tom,

We have few implementation queries in the draft
"draft-ietf-megaco-protocol-04.txt".

1. In section 8, it is mentioned that if a command in a Transaction Request
contains a wildcarded TerminationID, then a Response within the Transaction
Reply is included for each matching TerminationID.  Now take the case of an
AUDIT Command Request (whether Audit Cap. or  Audit Value) being sent from MGC
to MG for the audit all terminations of MG using wildcard . Considering 'N'
number of Terminations in MG ( N may be a large value, say, 10000) , then the
above logic may result into a reply which shall
contain N responses for single command in the Transaction Reply.
     Our query is can we split the number of responses in a single Reply by
having a upper bound on the number of Command Responses  being generated for a
single command Request or all the Responses should be sent in one shot for
wildcarded Terminations.

2.  In the Section 8, it is written that a Transaction guarentees ordered
Command processing. Moreover, a Transaction consist of one or more actions, an
action being identified by a ContextID.
     Now, if a transaction contains one or more actions ( i.e. multiple contexts
information) , how can one expect to have ordered processing across Contexts
because as far as our interpretation, the Contexts pertains to terminations in a
call and the ordered processing should be guarenteed within a context.
     With this point of view, one can have only single ContextID inofrmation in
a Transaction if a transaction guarentees ordered processing, except for the
case of MOVE command in which one can have multiple contextIDs in CALL
FORWARDING scenario.
Please through some light on this.

3.  If a particulat termination has been indicated to be hardware blocked by a
servicer change request from MG. Say if this termination was in some context,
then MGC will try to delete it from that context using the Megacop Subtract
command.
What does MG do in this case. Our understanding is that it will remove the
termination from the context. But then what happens to the embedded signals and
events specified for application in the subtract command. Do they get ignored or
an error condition is returned in the subtract response. Basically, what is the
MG behavior in such cases.

4.  In the ANNEX E.1 , the responses are acknowledged by "response
Acknowledgement parameter" to emulate three-way handshake, like TCP. However, in
the grammar, we are not having any such parameter to get the response
acknowledged.

5. As per the draft, in the MG configuration, a primary and the list of
secondary MGCs are configured. Our query is whether the secondary MGCs are meant
for redundant takeover in the case of MGC failure or its up to the implementor
to  configure secondary MGCs as redundant ones or not. In other words, if a MG
switches from a primary MGC to a secondary one, will all the ongoing
transactions stay or they be lost.

regards,

-Prashant Jain
( for Gateway Team, Hughes Software Systems)