Subject: Re: [Megaco] RE: Local control descriptor: mode

From: "Sean Leahy" <[email-masked]>
Date: Mon, 11 Mar 2002 14:56:58 +0000

In answer to Ian Leighton's two questions, I posit the following (sorry for
repeating some of these points):

Ian Leighton wrote:

-> "Specific question:

I'm not sure if I understand the requirement for the IG changes. Is the
requirement to send  mode=Send Recieve without a remote desciptor,
addressing a "common" MGC implementation problem? In short I'm
curious why it is difficult for the MGC to send mode = ReceiveOnly
when a remote descriptor is not present."

My comment is

-> There is no IG change.

The MGC is handling the inherent asymmetry in that one of the ADDs cannot
possibly contain a Remote Desriptor since the MG at the remote end only
chooses
the connection address for its ephemeral when it receives its  own ADD
request.
Neverthless, the MGC knows that the real requirement is mode = 'SendRecv'
and
does not want to keep another secondary and very transitory mode  - rather
it
knows very well what stage it is at in processing the connection and that
it has
yet to send a Remote Descriptor.

The temporary lack of a Remote Descriptor is an inherent constraint and
takes
place over a transitory state that should be under the control of the MGC
while
it is completing the handling of the new connection (MODIFY containing the
Remote Descriptor to follow very shortly).

The MG (slave) should trust that the MGC (controller) knows what it wants
to do !

Ian Leighton wrote:

-> "General question:

Some of the comments in this thread indicated that the MG should
have the ability to store and process when appropriate. There was
some disagreement about this capability but this certainly wasn't
a consensus.  Question: If the spec does not explicity state what an
MG should do given incomplete or conflicting settings should the
MG.

a) determine the most appropriate error descriptor to use and generate
an error reply or
b) reply indicating success and then wait for the MGC resolve the
conflict?"

My comment is

-> I think this is a bit too much of a generalisation. The MG action
depends
upon whether or not an incomplete/contradictory setting can be judged to
have
been received. In this specific case, the Local Control Descriptor (that
contains the mode) and Remote Descriptor are distinct. If it were really
thought
that they are interdependent at all times then it would seem to imply that
they
should really be one descriptor not two (not that I myself am arguing for
this).

The MG should obey the MGC commands and store the information as requested
rather
than usurp the controller's role by assuming an error.

There are other generally accepted cases where the MG may be expected to
retain
information but only act on it when it becomes appropriate (e.g. The Echo
Cancellation property in the TDM Circuit package may be set when there is
currently a simplex (or even loopback) connection.

Relatively dumb as the MG should be compared to its controller, it should
be able to
see that it cannot send data without a Remote Descriptor but should be
sending data
when the data is available, the mode is sendRecv and the Remote Descriptor
is present.

Regards
Ian Leighton

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Troy Cauble <[email-masked]>
Date: Tue, 12 Mar 2002 17:52:30 -0500

Comments below.
-troy

> yet to send a Remote Descriptor.

Doesn't want to keep a "secondary and very transitory mode"?!?
This model is *inventing* a transitory mode:  "SendRecv But Not Really".

It's going to bite people in the end, if referring to "being in
SendRecv mode" doesn't actually mean sending and receiving data.

Do we have to discuss what Inactive mode means?  Maybe if the mode is
"Inactive" but there's an RD, it should still be sending and receiving 
data?

Oh, let me guess.  Inactivity is *obviously* the default and sending/
receiving is *obviously* the AND of the conditions we've thought of
so far.

> The MG (slave) should trust that the MGC (controller) knows what it wants

Then maybe we should do away with error descriptors from the MG.
Whatever the MGC says makes sense by definition.

<snip>

> than usurp the controller's role by assuming an error.

Well, I don't see a command to "store" any "information".
I see a command to send and receive data.

---

From: Troy Cauble <[email-masked]>
Date: Tue, 12 Mar 2002 17:52:30 -0500

Comments below.
-troy

<snip>