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

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,

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

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

>
>
> 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 mode here affects the flow of media from the termination in and out
of
> > 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
>
> >
> >
> > 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

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

---

From: "Naveen Krishnan" <[email-masked]>
Date: Tue, 5 Mar 2002 09:11:49 +0800

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

http://www.gti.net/tla

---

From: "Naveen Krishnan" <[email-masked]>
Date: Tue, 5 Mar 2002 09:11:49 +0800

Hi Kevin,

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

http://www.gti.net/tla