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

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

_______________________________________________
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: Christer Holmberg <[email-masked]>
Date: Mon, 04 Mar 2002 08:36:07 +0200

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

---

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

Hi Dan,

I know.

Regards,

Christer Holmberg
Ericsson Finland