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

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

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 08 Mar 2002 13:27:03 +0200

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: Christer Holmberg <[email-masked]>
Date: Fri, 08 Mar 2002 13:27:03 +0200

Hi,

Regards,

Christer Holmberg
Ericsson Finland

---

From: Troy Cauble <[email-masked]>
Date: Fri, 08 Mar 2002 11:19:46 -0500

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: Troy Cauble <[email-masked]>
Date: Fri, 08 Mar 2002 11:19:46 -0500

-troy

---

From: Ian Leighton <[email-masked]>
Date: Fri, 08 Mar 2002 11:16:58 -0500

Hi All

There was some interesting comments made on this thread that I'm
having difficulties understanding. I have 2 questions, one which is
about the specific problem of mode = send receive and no remote
descriptor and the other is related to some of the comments about
general MG capabilities .

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.

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?

Regards
Ian Leighton

---

From: Ian Leighton <[email-masked]>
Date: Fri, 08 Mar 2002 11:16:58 -0500

Hi All

Specific question:

General question:

Regards
Ian Leighton