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: Christian Groves <[email-masked]>
Date: Mon, 04 Mar 2002 14:19:00 +1100

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

---

From: Christian Groves <[email-masked]>
Date: Mon, 04 Mar 2002 14:19:00 +1100

G'Day Tom,

Regards, Christian

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 04 Mar 2002 08:23:52 +0200

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 04 Mar 2002 08:23:52 +0200

Hi,

                   Media                 Media                Media

Regards,

Christer Holmberg
Ericsson Finland