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

From: "Tom-PT Taylor"<[email-masked]>
Date: Fri, 1 Mar 2002 11:39:57 -0500

We could add text of the form:

"If the MGC changes the mode of a stream to enable media flows in one or
both directions and the MG recognizes that it does not have enough
information on the termination concerned to allow the media to be processed
correctly, the MG MAY return an error but SHOULD instead wait for the
missing information to be provided."

This seems to reflect the consensus of the discussion.

-----Original Message-----
From: Terry L Anderson [mailto:[email-masked]]
Sent: Friday, March 01, 2002 11:17 AM
To: Christian Groves
Cc: [email-masked]'
Subject: Re: [Megaco] RE: Local control descriptor: mode

I'm a little uncertain as to what your preferrence is.  Are you arguing for
"no
change"?  or some statement involving "smart"?

Admittedly this section is normative but the SHOULD language makes it only
advisory.
My intention was language that would imply that MG was "smart enough".  That
is why
"necessary parameters" is NOT spelled out - MG should be smart enough to
know what is
necessary.

And referring to "parameters" (maybe theres a better word here) rather than
"descriptor" was exactly intended to allow the case, such as TDM, where MG
knows what
it needs without a descriptor.

I'm uncomfortable with Tom's reference to a descriptor being defined, but
can live
with no additional statement at all.

Christian Groves wrote:

> G'Day Terry,
>
> I'm a little uncomfortable adding such text in a normative fashion. As
> I've mentioned earlier and as Sean has alluded in a previous email, MG
> should be smart enough to figure out that if there's no remote
> descriptor then it can't send anything. There are cases such as TDM,
> multiplex terminations etc where you may not have a remote descriptor
> but want send/receive.
>
> I ran your proposed text past a few people and several of them asked
> "What are necessary parameters??" I think we put ourselves on a slippery
> slope with this statement.
>
> Lets just trust the MGC to know what's doing and let MG reply in the
> most appropriate manner.
>
> Regards, Christian
>
> Terry L Anderson wrote:
> >
> > Ah, the distinction between "until a Remote Descriptor is defined" and
"until a
> > Remote Descriptor is send" is perhaps too subtle.  I would not have
referred to
> > provisioned termination characteristics as having defined a
"Descriptor".  I
> > guess I think of a "Descriptor" as a part of a message carrying data
rather than
> > the data itself.  I would prefer language that made the choice more
apparent.
> > Something like:
> >
> > "An MGC SHOULD NOT send a LocalControl Descriptor with mode set to
send-only or
> > send/receive until the necessary parameters are defined by either a
Remote
> > Descriptor or provisioning."
> >
> > Note I am avoiding the text-encoding specific form "mode = " and using
the
> > generic language of 7.1.7.
> >
> > Tom-PT Taylor wrote:
> >
> > > My suggested language carefully skirted the issue of how the Remote
> > > Descriptor is known -- whether by provisioning or by explicit
declaration:
> > >
> > > "An MGC SHOULD NOT send mode = sendOnly or sendReceive until a Remote
> > > Descriptor is defined."
> > >
> > > -----Original Message-----
> > > From: Terry L Anderson [mailto:[email-masked]]
> > > Sent: Wednesday, February 27, 2002 2:07 PM
> > > To: Troy Cauble
> > > Cc: Sean Leahy; [email-masked]
> > > Subject: Re: [Megaco] RE: Local control descriptor: mode
> > >
> > > I've been traveling and so just catching up on this thread, but I
don't see
> > > anyone commenting on the issue that Remote and even Local are not
required
> > > for
> > > all terminations.  TDM terminations are often added without
Local/Remote.
> > > In
> > > fact we've been debating whether there is a useful form of SDP for TDM
> > > terminations.  Local and remote characteristics for TDMs (and
presumably
> > > other
> > > physical terminations) are usually just provisioned.
> > >
> > > I cannot see a way to provision all local and remote info for an
ephemeral
> > > since
> > > some sort of transport address would need to be assigned even for
non-RTP
> > > ephemerals, but anything we add about SHOULD NOT send mode=SendRecv or
> > > SendOnly
> > > without a Remote descriptor should be restricted to ephemerals.  The
nice
> > > thing
> > > about the suggestion that MG simply wait until it has enough info, is
that
> > > MG and
> > > MGC should know through provisioning what the minimum info is (whether
> > > Remote is
> > > required or is provisioned in the GW).
> > >
> > > Troy Cauble wrote:
> > >
> > > > Sean Leahy wrote:
> > > > >
> > > > > We would still argue that if the MG is relatively "dumb" and the
MGC is
> > > in
> > > > > control, the MGC may wish to send an ADD with the local control
> > > descriptor
> > > > > mode
> > > > > ==sendrecv && no remote descriptor followed by MODIFY with remote
> > > > > descriptor during the set-up phase for the connection.
> > > > >
> > > > > This saves the MGC having the overhead of holding  two states for
the
> > > mode
> > > > > (that required, and an extra one reflecting what has currently
been sent
> > > to
> > > > > the MG).
> > > > >
> > > > > If the MG is "dumb" , then it should not interpret this action by
its
> > > > > controller as an error but assume that the controller knows what
it
> > > wants
> > > > > to do.
> > > > >
> > > > > Any action by an MG that interprets the mode = sendrecv as an
explicit
> > > > > requirement to start sending media, and therefore produce an error
when
> > > the
> > > > > Remote Descriptor is not present, means that the MG is no longer
acting
> > > in
> > > > > a relatively dumb mode.
> > > >
> > > > Sounds pretty DUMB to me to try to send media without a Remote
Descriptor.
> > > > You want it to be SMART enough to not do that.
> > > >
> > > > I think you've twisted "dumb" and "smart" around to fit
> > > > what you think should happen!  But hey, it's just language.
> > > > We can make it mean whatever we want!
> > > >
> > > > <sarcasm>
> > > > [Not directed at Sean, but the larger concept of trickling the data
in...]
> > > >
> > > > Why make the poor MGC send the whole Remote Descriptor at
> > > > one time.  Let the SDP trickle in one line at a time.
> > > > If it looks incomplete to the MG, don't return an error,
> > > > just wait for more.
> > > >
> > > > Hmm, are whole lines of SDP too strict a requirement?
> > > > </sarcasm>
> > > >
> > > > -troy
> > > >
> > > > >
> > > > > The MG should let the MGC sort it out and retain what the MGC has
asked
> > > it
> > > > > to. The MGC should rely on its own logic to tell it when it has to
send
> > > the
> > > > > Remote Descriptor to complete the connection and to ensure it does
not
> > > > > leave the connection in an incomplete state.
> > > >
> > > > _______________________________________________
> > > > Megaco mailing list
> > > > [email-masked]
> > > > https://www1.ietf.org/mailman/listinfo/megaco
> > >
> > > --
> > >
> > > ------------------------------------------------------------
> > > Terry L Anderson              mailto:[email-masked]
> > > Tel:908.582.7013   Fax:908.582.6729
> > > Lucent Technologies/INS/Voice Over IP Access Networks
> > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
> > > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
> >
> > --
> >
> > ------------------------------------------------------------
> > Terry L Anderson              mailto:[email-masked]
> > Tel:908.582.7013   Fax:908.582.6729
> > Lucent Technologies/INS/Voice Over IP Access Networks
> > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
> > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

--

------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:908.582.7013   Fax:908.582.6729
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

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

---

From: Dan Elbert <[email-masked]>
Date: Mon, 04 Mar 2002 08:29:14 +0200

The mode here affects the flow of media from the termination in and out of
the context , and not inside the context.

Dan Elbert
RADVISION

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, March 04, 2002 8:24 AM
To: [email-masked]'
Subject: Re: [Megaco] RE: Local control descriptor: mode

Hi,

First, I have to admit I haven't followed this discussion in detail from the
beginning, so I appologise if my issues have already been discussed - or if
they
have nothing to do with what is discussed.

If we use a MUX termination (or any other "intermediate" termination), we
may have
one or more Stream descriptors defined inside that termination. Each of
those may
have a LocalControl descriptor, but since the termination "communicates"
with
other terminations INSIDE the same Context/MG there will most likely be no
Local-
and Remote descriptors. Still, however, the mode will be SendRecv when a
connection is established.

                   |-----------|         |-----------|       |-----------|
 ---- E1 ----|     T1       |------|  T_MUX |-----|   T2         |---- RTP
-----
                   |-----------|         |-----------|       |-----------|

                   Media                 Media                Media
                     Stream(s)              Stream(s)         Stream
                       LocalControl         LocalControl    LocalControl
                       Local
Local
                       Remote
Remote

Regards,

Christer Holmberg
Ericsson Finland

Christian Groves wrote:

> G'Day Tom,
>
> I think the text is close but "...SHOULD instead wait for the missing
> information to be provided." open up another issue. What does wait mean
> in this context? Wait before through connecting? Wait to send data?
>
> I'm happy to have this one clarified on the list rather than more
> additional text.
>
> Regards, Christian
>
> Tom-PT Taylor wrote:
> >

---

From: Dan Elbert <[email-masked]>
Date: Mon, 04 Mar 2002 08:55:04 +0200

Hi
What I meant is that the mode affects only the flows going in and out of the
context, so for a termination that is not connected to the outside like your
Mux termination, the localControl should not be used. You can control the
connection to other terminations with the Topology descriptor.

Dan

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, March 04, 2002 8:36 AM
To: Dan Elbert
Cc: [email-masked]'
Subject: Re: [Megaco] RE: Local control descriptor: mode

Hi Dan,

> the context , and not inside the context.

I know.

I just want to point out that we should not define a GENERIC rule to never
use
SendRecv without the Local- and Remote descriptors. If defined, it should be
clearly defined that it only affects terminations "connected" to remote
entities, outside the context.

Regards,

Christer Holmberg
Ericsson Finland

> > > I'm a little uncertain as to what your preferrence is.  Are you
arguing
> > > "descriptor" was exactly intended to allow the case, such as TDM,
where
> MG
> > > > > > fact we've been debating whether there is a useful form of SDP
for
> TDM
> > > > > > about the suggestion that MG simply wait until it has enough
info,
> is
> > > > > > > > This saves the MGC having the overhead of holding  two
states
> > > > > > > > If the MG is "dumb" , then it should not interpret this
action
> by
> > > > > > > > The MG should let the MGC sort it out and retain what the
MGC
> has
> > > > > > > > Remote Descriptor to complete the connection and to ensure
it
> does

---

From: "Kevin Boyle"<[email-masked]>
Date: Mon, 4 Mar 2002 16:01:59 -0500

Dan's point is that the Mode parameter only affects the termination with
respect to entities external to the context.  To control terminations with
respect to entities internal to the context, you would use Topology.  You
may have uses for other parameters in the LC descriptor.

Note that MGs are not required to support Topology, however...

Kevin

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, March 04, 2002 5:38 AM
To: Dan Elbert
Cc: [email-masked]'
Subject: Re: [Megaco] RE: Local control descriptor: mode

Hi,

> connection to other terminations with the Topology descriptor.

First, the LocalControl descriptor includes other properties than the mode,
why
you will need it. For example, there are MULTIPLEX PROPERTIES etc defined
for
the LocalControl descriptor.

Regards,

Christer Holmberg
Ericsson Finland

> > > > "If the MGC changes the mode of a stream to enable media flows in
one
> or
> > > > Admittedly this section is normative but the SHOULD language makes
it
> > only
> > > > advisory.
> > > > My intention was language that would imply that MG was "smart
enough".
> > That
> > > > is why
> > > > "necessary parameters" is NOT spelled out - MG should be smart
enough
> to
> > > > know what is
> > > > necessary.
> > > >
> > > > And referring to "parameters" (maybe theres a better word here)
rather
> > than
> > > > I'm uncomfortable with Tom's reference to a descriptor being
defined,
> > but
> > > > > I'm a little uncomfortable adding such text in a normative
fashion.
> As
> > > > > I've mentioned earlier and as Sean has alluded in a previous
email,
> > > > > > Ah, the distinction between "until a Remote Descriptor is
defined"
> > and
> > > > > > send/receive until the necessary parameters are defined by
either
> a
> > > > > > > I've been traveling and so just catching up on this thread,
but
> I
> > > > > > > without a Remote descriptor should be restricted to
ephemerals.
> > The
> > > > > > > > > We would still argue that if the MG is relatively "dumb"
and
> > > > > > > > > controller as an error but assume that the controller
knows
> > what
> > > > > > > > > requirement to start sending media, and therefore produce
an
> > error
> > > > > > > > [Not directed at Sean, but the larger concept of trickling
the
> > data
> > > > > > > > > to. The MGC should rely on its own logic to tell it when
it
> > has to

---

From: "Kevin Boyle"<[email-masked]>
Date: Tue, 5 Mar 2002 12:56:53 -0500

Section 7.1.18 reads, "... The Topology Descriptor is optional to
implement."

Now, whether this should be changed or not is a different debate.  But, at
this moment, Topology is not required.

Kevin

-----Original Message-----
From: Naveen Krishnan [mailto:[email-masked]]
Sent: Monday, March 04, 2002 8:12 PM
To: Boyle, Kevin [NCRTP:3Z30:EXCH]
Cc: [email-masked]
Subject: Re: [Megaco] RE: Local control descriptor: mode

Hi Kevin,

Can u explain the above in detail.

-Naveen
----- Original Message -----
From: Kevin Boyle <[email-masked]>
To: Christer Holmberg <[email-masked]>; Dan Elbert
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, March 05, 2002 5:01 AM
Subject: RE: [Megaco] RE: Local control descriptor: mode

> > > The mode here affects the flow of media from the termination in and
out
> of
> > SendRecv without the Local- and Remote descriptors. If defined, it
should
> be
> > > First, I have to admit I haven't followed this discussion in detail
from
> > the
> > > beginning, so I appologise if my issues have already been discussed -
or
> > if
> > > other terminations INSIDE the same Context/MG there will most likely
be
> no
> > > > > > > guess I think of a "Descriptor" as a part of a message
carrying
> > > > > > > "An MGC SHOULD NOT send a LocalControl Descriptor with mode
set
> > > > > > > Note I am avoiding the text-encoding specific form "mode = "
and
> > > using
> > > > > > > > "An MGC SHOULD NOT send mode = sendOnly or sendReceive until
a
> > > > > > > > anyone commenting on the issue that Remote and even Local
are
> > > > > > > > I cannot see a way to provision all local and remote info
for
> an
> > > > > ephemeral
> > > > > > > > since
> > > > > > > > some sort of transport address would need to be assigned
even
> > > > > > > > MGC should know through provisioning what the minimum info
is
> > > (whether
> > > > > > > > > > ==sendrecv && no remote descriptor followed by MODIFY
with
> > > remote
> > > > > > > > > > Any action by an MG that interprets the mode = sendrecv
as
> > > > > > > > > > Remote Descriptor is not present, means that the MG is
no
> > > longer

---

From: "Kevin Boyle"<[email-masked]>
Date: Tue, 5 Mar 2002 12:56:53 -0500

Kevin

-----Original Message-----
From: Naveen Krishnan [mailto:[email-masked]]
Sent: Monday, March 04, 2002 8:12 PM
To: Boyle, Kevin [NCRTP:3Z30:EXCH]
Cc: [email-masked]
Subject: Re: [Megaco] RE: Local control descriptor: mode

Hi Kevin,

-Naveen
----- Original Message -----
From: Kevin Boyle <[email-masked]>
To: Christer Holmberg <[email-masked]>; Dan Elbert
<[email-masked]>
Cc: <[email-masked]>

out
should
from
or
be
carrying
set
and
a
are
for
even
is
with
as
no

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Wed, 6 Mar 2002 07:43:10 -0500

This interpretation makes me very uneasy.  You still have to describe the
media flowing between a MUX termination and the rest of the context.  The
fact that the MUX termination hides the terminations it contains doesn't
prevent the flows it supports from passing to and from the exterior (even
though the flow is indirect, through the contained terminations).  That
means you can still control whether or not a given media flow is active
using mode.

-----Original Message-----
From: Dan Elbert [mailto:[email-masked]]
Sent: Monday, March 04, 2002 1:55 AM
To: 'Christer Holmberg'; Dan Elbert
Cc: [email-masked]'
Subject: RE: [Megaco] RE: Local control descriptor: mode

Hi

Dan

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, March 04, 2002 8:36 AM
To: Dan Elbert
Cc: [email-masked]'
Subject: Re: [Megaco] RE: Local control descriptor: mode

Hi Dan,

I know.

Regards,

Christer Holmberg
Ericsson Finland

arguing
where
for
info,
states
action
MGC
it

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Wed, 6 Mar 2002 07:43:10 -0500

-----Original Message-----
From: Dan Elbert [mailto:[email-masked]]
Sent: Monday, March 04, 2002 1:55 AM
To: 'Christer Holmberg'; Dan Elbert
Cc: [email-masked]'
Subject: RE: [Megaco] RE: Local control descriptor: mode

Hi

Dan

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, March 04, 2002 8:36 AM
To: Dan Elbert
Cc: [email-masked]'
Subject: Re: [Megaco] RE: Local control descriptor: mode

Hi Dan,

I know.

Regards,

Christer Holmberg
Ericsson Finland

arguing
where
for
info,
states
action
MGC
it

---

From: "Sean Leahy" <[email-masked]>
Date: Fri, 8 Mar 2002 11:02:48 +0000

As regards Christian Groves's question about Mode = SendRecv but no Remote
Descriptor:

     "What does wait [for a Remote Descriptor] mean in this context? Wait
before through connecting? Wait to send data?"

     I think it should simply mean wait before sending data (there is
nothing to stop the MG receiving data).

     The MG should make whatever connection(s) and media flows as there is
information available for.  If we have an end/receive mode, but no remote
SDP, then we cannot make an outgoing media flow, but we probably can make
an incoming media flow.

     Regards,
     Sean Leahy

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Fri, 8 Mar 2002 08:12:18 -0500

As I see it, we do have Local and Remote descriptors for TDM.  They are
provisioned defaults rather than explicitly specified.

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Friday, March 08, 2002 6:27 AM
To: Sean Leahy
Cc: Christian Groves; Taylor, Tom-PT [CAR:B800:EXCH]; 'Terry L
Anderson'; 'derrick.ding'; [email-masked]'
Subject: Re: [Megaco] RE: Local control descriptor: mode

Hi,

A TDM termination is another example where we may never have a Local- and
Remote descriptor, and still the mode will be SendRecv when the connection
is
established.

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Tom-PT Taylor"<[email-masked]>
Date: Fri, 8 Mar 2002 08:26:06 -0500

The default for RTP would be whatever is provisioned on the MG for RTP.
That may well be "absent", exactly as you say.  For TDM, at the least the
provisioned contents would have to indicate A-law vs. mu-law encoding.

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Friday, March 08, 2002 8:22 AM
To: Taylor, Tom-PT [CAR:B800:EXCH]
Cc: Sean Leahy; Christian Groves; 'Terry L Anderson'; 'derrick.ding';
[email-masked]'

Hi, 
As I see it, we do have Local and Remote descriptors for TDM.  They are
provisioned defaults rather than explicitly specified.
So, if they are default for a TDM termination, why are they not default for
a RTP termination? 
And, what would the default contain of the descriptors be? I'd say they
would be empty, which is the same they wouldn't be there at all... 
Regards, 
Christer Holmberg 
Ericsson Finland 

-----Original Message----- 
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Friday, March 08, 2002 6:27 AM 
To: Sean Leahy 
Cc: Christian Groves; Taylor, Tom-PT [CAR:B800:EXCH]; 'Terry L 
  
Hi,

---

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

Troy,
     I believe that there is really only one answer here - the Mode
reported should be the Mode as stored (i.e. SendRecv), that is what the
controller asked for and what the MG supplied. The lack of a Remote
Descriptor can also be audited by the MGC.

     Note that the Local Control Descriptor and Remote Descriptor are
distinct. If it were really thought that they are so 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).

     Regards,
     Sean

Troy Cauble <[email-masked]>@ietf.org on 08/03/2002 16:19:46

Sent by:  [email-masked]

To:   "[email-masked]'" <[email-masked]>
cc:

Another downside to things like Mode = SendRecv but no
Remote Descriptor:

What Mode does such an endpoint claim to be in
if Audited?  And how do we refer to it?

Is it *IN* whatever-the-last-mode-was, but it wants to
be in SendRecv?  Or is it already *IN* SendRecv mode?

If we refer to it as already being IN SendRecv mode,
that flies against the standard meaning of the phrase.
(I think if something is "in SendRecv mode" it's actually
sending and receiving data.)

So even without Audits, I think this is a road to confusing
terminology.

People will write requirements about what a box should
do "in SendRecv mode".  What will that mean?

I think allowing things like Mode = SendRecv but no Remote
Descriptor is actually inventing a bunch of transition
modes and we have no framework for discussing them.

-troy

"When I use a word," Humpty Dumpty said, in a rather
scornful tone, "it means just what I choose it to
mean-neither more nor less." "The question is," said Alice,
"whether you can make words mean so many different
things."
                Lewis Carroll [Charles Lutwidge Dodgson],
                Alice's Adventures in Wonderland (1865).

---

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

Troy,

     Regards,
     Sean

-troy

---

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