Subject: Some Megaco Queries

From: Prashant Jain <[email-masked]>
Date: Tue, 2 Nov 1999 10:00:36 +0530

Sorry, I forgot to mention the subject in my previous mail. I am resending it as
follows  with subject. Kindly ignore the previous copy of it.

Regards,
Prashant Jain

--------------------------------------------------------- Earlier mail
      -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

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)

---

From: Brian Rosen <[email-masked]>
Date: Tue, 2 Nov 1999 20:23:54 -0500

> contain N responses for single command in the Transaction Reply.
This is correct.

> single command Request or all the Responses should be sent in
Although such ideas have been discussed, there has never been any real
consensus on how to limit the size of a response.  The current "best
practice"
is to structure the names of your terminationIDs and use wildcards to limit
the information transferred.
> Please through some light on this.
There are some cases where MGCs wish to control the order of execution
between contexts.  An example is where it needs to free resources from one
context before using it in another.  Thus, actions within transactions are
executed in order, and commands within actions are executed in order.

Transactions are not necessarily executed in order, and in fact can be
executed "simultaneously" if the entity is able to.

> MG behavior in such cases.
I'm confused by this question, since subtract normally does not have
any events or signals descriptors - the termination assumes the events and
signals it has in null state.  I would expect that if the termination was
out of service, it would be incapable of detecting the events or applying
any signals specified.

> the grammar, we are not having any such parameter to get the response
This has been addressed in the latest (Red Bank, v12) draft

> transactions stay or they be lost.
Think of the primary and secondary MGCs as an ordered list, with the primary
at the head of the list.  The MG tries each of the MGCs in it's list, in
order, until it finds one that will serve it.  Normally, the first MGC in
the list (the primary) will serve it, but if that MGC is unavailable, the MG
may contact
the next MGC in it's list, and if that MGC is unavailable, the next, and so
on.
The MG=MGC association is not redundant.  If the current association fails
(MGC
failure), the MG tries to establish a new one.  If it gets a new
association,
the new MGC can audit the state of the MG to find out current state,
whatever it is.  We have defined transactions as not having "roll back"
behavior, so that transactions in process when the association failure is
detected probably complete (assuming no further error), but the MG is not
obligated to do so.  What it can't do is get a reply back to the MGC.

Brian

---

From: Chuong Nguyen <[email-masked]>
Date: Wed, 3 Nov 1999 09:14:32 -0600

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.

     [[TomT]]
     I agree that we should specify behaviour for out of service
terminations.  It seems fairly clear that while a termination is out of
service (as opposed to under test) signals cannot be
     applied to it and it will not report events.  The question is
whether we want deferred support of events and signals -- the ability to
provide descriptors which apply only when the
     termination returns to service.  For signals at least I suspect the
answer is NO: the loss of control over timing of the application of the
signal would be unacceptable in most cases.  So
     the only question is whether we want to allow the MGC to specify an
event descriptor for an out of service termination, to take effect when
it returns to service.

Tom
Your above statements lead me to come up with the following cases.
Can you give me some comments on each case?

Thanks
Chuong

Case 1:
 Context A has a physical termination and an ephemeral termination.
MG sends a ServiceChange Forced to let MGC knows that the physical
termination has been taken out of service
Is the physical termination taken out Context A and put back in the Null
Context by the MG before sending the ServiceChange?
Or the termination stays in the Context A and marked as out of service
and the MGC is required to send a Subtract to MG to
remove it from Context A and put it into the Null Context?  If yes, it
also implies that there should be statistic available if MGC
asks for it.

Case 2:
 Context A has a physical termination and an ephemeral termination.
Same question as Case 1 except I assume the MG will either remove the
ephemeral from the context or leave it in the context until
MGC Subtract it.

Case 3:
Context A has a physical termination and an ephemeral termination.
MG sends a ServiceChange Forced to let MGC knows that both terminations
have been taken out of service
Does the MG remove the context or waits for MGC to send a Subtract to
remove the context?

Case 4:
 Context A has a physical termination and an ephemeral termination.
MG sends a ServiceChange Graceful with a delay of 10 seconds for both
terminations
It is clear that if MGC sends Subtract to MG for both terminations
before the delay, Context A is removed.
But if MGC does not send the Subtract to MG before the delay, thus after
the delay will the MG remove Context A
and mark the physical termination as out of service in the Null Context?

Case 5:
 Context A has a physical termination and an ephemeral termination.
MG sends a ServiceChange Graceful with a delay of Null for both
terminations
This case is clear that the terminations will be Subtract through nornal
ending of the call.
After the Subtract , MG will mark the physical termination as out of
service in the Null Context.

--
  Alcatel USA, Inc             Internet: [email-masked]
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****