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

From: "Sean Leahy" <[email-masked]>
Date: Wed, 27 Feb 2002 16:06:38 +0000

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.

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.

Regards,
Sean Leahy

"Blatherwick, Peter" <[email-masked]>@ietf.org on 27/02/2002
14:38:38

Sent by:  [email-masked]

To:   "'Tom-PT Taylor'" <[email-masked]>, "'Dan Elbert'"
      <[email-masked]>, "[email-masked]'" <[email-masked]>
cc:

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

Tom, Dan, list,

   >I would hope someone else would have an opinion on this topic.  It's a
   >little hard to call a consensus if only a couple of people are involved
in
   >the discussion.

Just to let you know other eyes are at least watching, I also think this is
the right type of statement to make, i.e. MGC SHOULD NOT say something
nonsensical, like sendrecv sent if there is no remote descriptor.  MG
should not be required to be smart about this sort of stuff in any way, as
it will inevitably lead to different MG implementations making different
assumptions about what is "smart", real bad for interop.  (I expect there
are other cases floating around, but may as well specifically catch the
ones we've found.)

-- Peter Blatherwick

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: February 27, 2002 08:26
To: [email-masked]'
Subject: RE: RE: [Megaco] RE: Local control descriptor: mode

If that's OK with everyone, Terry please note.

-----Original Message-----
From: Dan Elbert [mailto:[email-masked]]
Sent: Wednesday, February 27, 2002 8:13 AM
To: Taylor, Tom-PT [CAR:B800:EXCH]; Dan Elbert; [email-masked]'
Subject: RE: RE: [Megaco] RE: Local control descriptor: mode

Is not a contradiction, I argued that the MGC is responsible of sending
commands that make sense, and if in this case is not clear what make sense,
let's clarify it in the IG (with a SHOULD NOT as you say).

Dan

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Wednesday, February 27, 2002 3:06 PM
To: 'Dan Elbert'; [email-masked]'
Subject: RE: RE: [Megaco] RE: Local control descriptor: mode

Right up to your last sentence I figured the consensus was fairly clear,
and
it ran against what I had been arguing.  Your last sentence contradicts
what
came before.  Perhaps you were just offering that as an alternative, or
perhaps it might work if we make it SHOULD strength: an MGC SHOULD NOT send
mode = sendOnly or sendReceive until a Remote Descriptor is defined.

-----Original Message-----
From: Dan Elbert [mailto:[email-masked]]
Sent: Wednesday, February 27, 2002 3:28 AM
To: Taylor, Tom-PT [CAR:B800:EXCH]; [email-masked]'
Subject: RE: RE: [Megaco] RE: Local control descriptor: mode

Hi
I'd say option 2 - keep the mode and use it when relevant.
This is for two reasons
1. Like people said, the MG stores attributes and applies them whem
relevant.
2. In the past was said that the MGC is responsible for the correct
operation of the MG, we cannot make the MG so robust that it will work in
any crazy scenary that the MGC can create because in that case we lost the
"simple" and "dumb" that are in the MG description.
So I think this shouldn't be a big deal if the MGC is doing is job rigth.
We can also put a note in the IG that sendrecv cannot be sent if there is
no
remote descriptor.

Dan Elbert
RADVISION

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Monday, February 25, 2002 10:16 PM
To: [email-masked]'
Subject: RE: RE: [Megaco] RE: Local control descriptor: mode

I would hope someone else would have an opinion on this topic.  It's a
little hard to call a consensus if only a couple of people are involved in
the discussion.

-----Original Message-----
From: Sean Leahy [mailto:[email-masked]]
Sent: Monday, February 25, 2002 4:18 AM
To: Taylor, Tom-PT [CAR:B800:EXCH]
Cc: 'derrick.ding'; Megaco
Subject: RE: RE: [Megaco] RE: Local control descriptor: mode

Tom,
     The point about an incomplete remote descriptor seems only tenuously
related to the original question about the local control descriptor mode
==sendrecv && no remote descriptor present.

     The decision about when to send the required mode and remote
descriptor attributes is surely a controller issue whereas a decision about
the validity of a received remote descriptor is an issue for the MG -
however the preceding question is resolved.

Regards,
Sean Leahy

"Tom-PT Taylor"<[email-masked]>@ietf.org on 25/02/2002 02:27:06

Sent by:  [email-masked]

To:   "'derrick.ding'" <[email-masked]>
cc:   Megaco <[email-masked]>

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

I think this is an invitation to undetected call failures.  Suppose part of
the Remote Descriptor is specified, but not enough to start sending
packets.
So the MG does not send packets, and the user experiences "can hear, can't
be heard".  At least if the MG flags an error condition, there should be a
log somewhere so the condition can be debugged.

-----Original Message-----
From: derrick.ding [mailto:[email-masked]]
Sent: Sunday, February 24, 2002 8:59 PM
To: Taylor, Tom-PT [CAR:B800:EXCH]
Cc: Megaco
Subject: Re: RE: [Megaco] RE: Local control descriptor: mode

Hi,Tom-PT Taylor£¡
      I don't think it's hard for MG to make a decision.
      Mode and remote descriptor are two key parameters for MG to connect
remote termination. So MG will judge (mode ==sendrecv && remotedescriptor
present) every time before remote connection.
      And as sean leahy said,  the GW stores attributes provided by the MGC
and acts when the combination of attributes determine it do so.

2002-02-24 18:17:00 you write£º
>I certainly don't feel on firm ground arguing one side or the other on
this
>point.  The asymmetry in call flow that you point out is a fact, but it is
>easy enough to modify the mode from receiveOnly to sendReceive when you
come
>back to add that Remote Descriptor.  What tips the balance in my mind is
the
>fact that at some point the MG has to decide whether or not it should be
>transmitting packets, and it's harder to do if mode is not the parameter
>controlling the decision.
>
>
>-----Original Message-----
>From: Sean Leahy [mailto:[email-masked]]
>Sent: Thursday, February 14, 2002 9:42 AM
>To: Taylor, Tom-PT [CAR:B800:EXCH]; derrick.ding; Wayne Cutler
>Cc: Megaco
>Subject: Re: [Megaco] RE: Local control descriptor: mode
>
>
>Re:  "it's confusing/invalid for the GW to be told "sendrecv" without a
>corresponding Remote Descriptor":
>
>Alternatively: it should not be confusing given the view that the GW
stores
>attributes provided by the MGC and acts when the combination of attributes
>determine it do so. I am sure there are other cases where attibutes
>provided to the MG are not relevent immediately or in all intermediate
>states (e.g. The Echo Cancellation property in the TDM Circuit package may
>be set but at present there may be a simplex (or even loopback)
connection.
>We would expect the MG to retain the information but only act on it when
it
>becomes appropriate).
>
>We  posit a design that ADDs an ephemeral at one end of a connection
>without a remote descriptor and then provides the remote descriptor via a
>MODIFY. The MGC does not expect an Error 411 to this ADD request simply
>because the mode in the Local Control descriptor is set to SendRecv but
>there is no remote descriptor !
>
>There is an inherent requirement to support an ADD with the remote
>descriptor/capabilities not immediately known at one end of a connection:
>
>-    When an MGC allows the MG to choose the connection address for the
>ephemeral, it cannot know the full connection details that need to be
>provided to the other end until after the first ADD is successfully
>performed. Therefore, whichever end receives the first ADD request can
>never have a Remote Descriptor.
>
>-    In contrast, the second ADD is provided with the Remote Descriptor as
>it is available once the connection details have been determined by the MG
>in response to the first ADD request.
>
>-    i.e. There is an inherent protocol asymmetry in the two ADD cases
>(first and second) that we expect the MG to be capable of understanding.
>
>Note also : Appendix A of RFC 3015 has an example (at 'A.1.1 Programming
>Residential GW Analog Line Terminations for Idle Behaviour') where the MGC
>programs a Termination in the NULL context. The MGC provides a Local
>Control descriptor mode of SendReceive with Echo Cancellation
>characteristics, a Local descriptor but no Remote Descriptor.
>
>Sean Leahy
>
>
>
>"Wayne Cutler" <[email-masked]>@ietf.org on 06/02/2002 09:02:25
>
>Sent by:  [email-masked]
>
>
>To:   [email-masked]
>cc:   Megaco <[email-masked]>
>
>Subject:  Re: [Megaco] RE: Local control descriptor: mode
>
>>In my opinion, Error 441 Missing Remote or Local Descriptor applies here.
>>Unfortunately I can't find the text to support that opinion.  I therefore
>>have to put the question to the list: what do other people think?
>
>I would agree with you. In the original example, it's confusing/invalid
for
>the  GW to be told "sendrecv" without a
> corresponding Remote Descriptor.
>
>Wayne.
>
>
>
>------------
>This e-mail and any attachments are confidential.  If you are not the
>intended recipient, please notify us immediately by reply e-mail and then
>delete this message from your system. Do not copy this e-mail or any
>attachments, use the contents for any purpose, or disclose the contents to
>any other person: to do so could be a breach of confidence.
>
>_______________________________________________
>Megaco mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/megaco
>
>
>
>"Tom-PT Taylor"<[email-masked]>@ietf.org on 05/02/2002 17:16:51
>
>Sent by:  [email-masked]
>
>
>To:   "derrick.ding" <[email-masked]>
>cc:   Megaco <[email-masked]>
>
>Subject:  [Megaco] RE: Local control descriptor: mode
>
>
>
>In my opinion, Error 441 Missing Remote or Local Descriptor applies here.
>Unfortunately I can't find the text to support that opinion.  I therefore
>have to put the question to the list: what do other people think?
>
>
>-----Original Message-----
>From: derrick.ding [mailto:[email-masked]]
>Sent: Tuesday, February 05, 2002 1:00 AM
>To: Taylor, Tom-PT [CAR:B800:EXCH]
>Cc: Megaco
>Subject: Local control descriptor: mode
>
>
>Hi,Tom-PT£¡
>     A question about Local control descriptor: mode
>
>     When MGC apply for RTP resource to MG without the remote RTP SDP, and
>MGC set the Local control descriptor of Ephermeral termination as
>SendRecv(not RecvOnly). As following shows:
>    Transaction = 100003{
>      Context = 3 {
>         Add = $ {
>              Media {
>                Stream = 1 {
>                   LocalControl {
>                        Mode = SendRecv
>                         }
>                   Local {
>             v=0
>             c=IN IP4 $
>             m=audio $ RTP/AVP 4
>             a=ptime:30
>                         }
>                        }
>                    }
>                  }
>        }
>     }
>
>What is suggested that MG should do? There are several choice on MG side:
>1. since there's no remote port to connect, MG reply Add Error to MGC.
>
>2. since there's no remote port to connect, MG ignore it, send reply with
>Local SDP to MGC, and keep the mode.
>   When modify command with Remote RTP SDP comes, MG will connect the
local
>port with remote port. This time mode is not mandatory.
>Like this:
>      Transaction = 100004{
>      Context = 3 {
>        modify = A4445 {
>              Media {
>                Stream = 1 {
>                   Remote {
>             v=0
>             c=IN IP4 125.125.125.111
>             m=audio 1111 RTP/AVP 4
>                         }
>                        }
>                    }
>                  }
>        }
>     }
>
>Now what's the correct operation on MG side?
>
>Thanks and Best Regards
>
>            derrick.ding
>            [email-masked]
>
>
>_______________________________________________
>Megaco mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/megaco
>
>
>
>
>
>------------
>This e-mail and any attachments are confidential.  If you are not the
>intended recipient, please notify us immediately by reply e-mail and then
>delete this message from your system. Do not copy this e-mail or any
>attachments, use the contents for any purpose, or disclose the contents to
>any other person: to do so could be a breach of confidence.

            derrick.ding
            [email-masked]

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

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

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

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

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

---

From: Ian Leighton <[email-masked]>
Date: Wed, 27 Feb 2002 12:35:27 -0500

Hi Sean

IMO the action that is being requested is to set the mode to sendrecv. In the
process of doing this the MG determines that it doesn't have the required
info (ie the remote descriptor) so it replies with an error.

The suggestion that the MG should NOT assume that the request is to be
done immediately leads to futher ambiguities.

I know that I'am stretching this (ie. the following questions are retorical)
but
given your comments below can an MGC modify a termination that is an
active context but indicate the NULL context because it knows that termination

will soon be subtracted? Or can an MGC add an out of service termination
to a context because the termination will soon be put back into service?

Regards
Ian Leighton

---

From: Ian Leighton <[email-masked]>
Date: Wed, 27 Feb 2002 12:35:27 -0500

Hi Sean

Regards
Ian Leighton

---

From: Troy Cauble <[email-masked]>
Date: Wed, 27 Feb 2002 13:03:45 -0500

> Remote Descriptor is not present, means that the MG is no longer acting in

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

---

From: Troy Cauble <[email-masked]>
Date: Wed, 27 Feb 2002 13:03:45 -0500

<sarcasm>

-troy

---

From: Terry L Anderson <[email-masked]>
Date: Wed, 27 Feb 2002 14:07:03 -0500

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).

--

------------------------------------------------------------
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

---

From: Terry L Anderson <[email-masked]>
Date: Wed, 27 Feb 2002 14:07:03 -0500

--