Subject: Re: T4) rx/tx Descriptor vs local/remote Descriptor

From: Fernando Cuervo <[email-masked]>
Date: Fri, 13 Aug 1999 10:12:28 -0400

I know my response is not going to help clarifying, but I agree with the
folks that want to reinstate local/remote as originaly used in the MGCP
model. We need a new name for the descriptor that is now known as local, I
have proposed "mgcmg", other terms I've heard are "private" "internal"

Fernando

> ----------
> From:         Brian Rosen[SMTP:[email-masked]]
> Sent:         August 12, 1999 7:37 PM
> To:   [email-masked]
> Subject:      Re: T4) rx/tx Descriptor vs local/remote Descriptor
>
> I readily admit to not really understanding all of this issue.
>
> There needs to be a descriptor which describes items of interest
> only between the MGC and MG.  There needs to be at least one
> descriptor that is primarily of interest between the two MGs.  The
> format of the former is like that of all the other descriptors, the format
> of the latter is SDP or any other alternate we agree on.
>
> The former should be called "local".
>
> If there is indeed only one SDP/whatever descriptor, it should be
> called "remote".  If there needs to be two descriptors representing
> information of interest to the two MGs, then we need two names,
> and Tom proposed "send and receive" which I renamed "rx" and "tx".
>
> Brian
>
> > -----Original Message-----
> > From: Nancy-M Greene [mailto:[email-masked]]
> > Sent: Thursday, August 12, 1999 1:33 PM
> > To: [email-masked]
> > Subject: T4) rx/tx Descriptor vs local/remote Descriptor
> >
> >
> > > T4) Section 6.2.3.5: ***There is still an issue with tx and
> > rx descriptor
> > > names: when you do an add on the RTP termination, in the
> > response you will
> > > get params for RxDescriptor (local information). BUT it is
> > also a transmit
> > > descriptor. So, there is still a wish to call rxDescriptor the
> > > localDescriptor, and txDescriptor the remoteDescriptor. Note added.
> > >
> > There seems to be strong support for renaming the rx and tx
> > Descriptors to
> > be local and remote Descriptors - see the argument below from
> > Christian
> > Huitema, it is also the argument Chip Sharp brought up at the
> > ITU meeting.
> > When this thread happened, a number of others also preferred
> > the names local
> > and remote for these descriptors.
> >
> > From Christian Huitema's email of July 22/99 title "RE:
> > Local, RX and TX
> > descriptors":
> > I think we are drifting on the wrong track there.  In fact, I
> > believe that
> > "Tx, Rx" are soemwhat misleading names.  let's face it, it
> > always take two
> > to communicate. My prefered acronym is "local., remote", not
> > "transmit,
> > receive."  Local = my address, my port, both for transmit and receive.
> > Remote = remote address, remote prot, both for transmit and receive.
> >  True, the need to know the remote transmit port is a bit
> > fuzzy -- it only
> > provides weak security.  By definition, all these information apply to
> > simplex and duplex channels alike.
> > ---------
> >
> > Proposal:
> > - rename: localDescriptor to internalDescriptor, rxDescriptor to
> > localDescriptor, and txDescriptor to remoteDescriptor.
> > Note: internalDescriptor is information shared between the
> > MGC and the MG
> > that is not of interest to the remote MG. This could be
> > policy information
> > the MGC wants to share with the MG, such as the order in
> > which to choose a
> > codec, or it could be information such as gain or echo
> > cancellation that are
> > parameters set on the MG, but are of no interest to the other MG.
> >
> > Nancy
> > --------------------------------------------------------------
> > ------------
> > Nancy M. Greene
> > Internet & Service Provider Networks, Nortel Networks
> > T:514-271-7221 (internal:ESN853-1077) E:[email-masked]
> >
> > --------------------------------------------------------------
> > ------------
> > Nancy M. Greene
> > Internet & Service Provider Networks, Nortel Networks
> > T:514-271-7221 (internal:ESN853-1077) E:[email-masked]
> >
>

---

From: Nancy-M Greene <[email-masked]>
Date: Fri, 13 Aug 1999 11:23:55 -0500

How about localStreamOptionsDescriptor?

Then we have the information that needs to be shared between MGs:

- localDescriptor for information such as my address, my port, for both
transmit and receive
- remoteDescriptor for remote address and port, for both transmit and
receive

and we have the information of interest only between the MGC and the MG:

- localStreamOptionsDescriptor for gain, echo cancellation, MGC's proposed
order of codecs for the MG to choose when it has a choice, etc.

Nancy
--------------------------------------------------------------------------
Nancy M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:[email-masked]

> ----------
> From:         Cuervo, Fernando [CAR:5N10-I:EXCH]
> Sent:         Friday, August 13, 1999 10:12 AM

---

From: Nancy-M Greene <[email-masked]>
Date: Fri, 13 Aug 1999 12:38:29 -0500

Well, I prefer Abdallah Rayhan's  names, adding Descriptor to them:

"LocalDescriptor" is MG-MGC
"MGLocalDescriptor" is MG-MG Local
and "MGRemoteDescriptor" is MG-MG Remote

Nancy

> ----------
> From:         Greene, Nancy-M [CAR:5N10:EXCH]
> Sent:         Friday, August 13, 1999 12:23 PM

---

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 18 Aug 1999 17:31:23 -0400

I'll surrender on terminology so long as the point is accepted that
LocalStuff has to include activity status of the stream concerned at the MG
to which the LocalStuff is being sent.  One implication of this is that in
the early stages of the call LocalStuff for MG A will typically differ from
LocalStuff for MG B (e.g. to start with, A would be receiveonly, B sendonly,
so the network beyond B can send tones or announcements back along the path
B-A-whatever comes after that).

> From: Chip Sharp [SMTP:[email-masked]]
> Sent: Wednesday, August 18, 1999 5:03 PM
> Okay,  I'll try to explain what I'm thinking about.  Hopefully someone can
> correct me where I mess it up.  I'm assuming that an MGC controls both MGs
> used for the call.
>
> Assume MGC is setting up a call between MG-A and MG-B.
> The MGC sends an ADD to MG-A.  Included in the ADD is information about
> the
> call that the MGC wants MG-A to use (policy stuff).  I'll call this the
> LocalStuff ("LS") descriptor.
>
> MG-A returns a session description in SDP describing the session
> parameters
> to use for the call.  For example, for the RTP termination this would have
> the IP address and port number to use for the RTP traffic.  This would be
> contained in what I call the LocalDescriptor.
>
> The MGC then contacts MG-B.  It passes the information for the call in the
> LocalStuff descriptor.  It also passes the SDP received from the MG-A to
> MG-B in the RemoteDescriptor.  MG-B returns its session info to the MGC in
> its LocalDescriptor.
>
> MGC then sends a MODIFY to MG-A containing a RemoteDescriptor with the
> session info received from MG-B.
>
> I guess that you could use TxDescriptor instead of RemoteDescriptor and
> RxDescriptor instead of LocalDescriptor if you wish.
>
> I found it easier to think of these descriptors as defining the remote
> side
> and the local side of the call.
>
>
> Chip
>
>
> At 07:37 PM 8/12/99 -0400, Brian Rosen wrote:
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------

---

From: Brian Rosen <[email-masked]>
Date: Fri, 20 Aug 1999 10:06:24 -0400

With Tom Taylor's blessing, we propose to adopt this view,
using the terms "LocalControl" instead of "LocalStuff".

I propose the following text:
The LocalControl Descriptor contains the Mode parameter and
properties of a termination (defined in Packages) that are
stream specific, and are of interest between the MG and the MGC.

The Local and Remote Descriptors contain the parameters
describing the flows sent to and received from the MG,
and are of interest between two MGs.  They are encoded as SDP
strings as specified in RFC2327, or tag-value pairs as defined
in Annex D.  Local is the capability of the local MG and is
typically sent from MG to MGC, and subsequently used as part
of a capability negotiation between two MGCs.  Remote is the
parameters describing the flows the remote MG will send/receive,
is typically sent from MCG to MG, and is the result of the
capability negotiation.  Between two MGs A and B, MG A receives
a negotiated version of MG B's Local Descriptor as its Remote
Descriptor, and MG B receives a negotiated version of MG A's
Local Descriptor as its Remote Descriptor.

Brian

> From: Chip Sharp [mailto:[email-masked]]
> To: Brian Rosen; [email-masked]
> The MGC sends an ADD to MG-A.  Included in the ADD is
> information about the
> MG-A returns a session description in SDP describing the
> session parameters
> I found it easier to think of these descriptors as defining
> the remote side

---

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 20 Aug 1999 10:24:02 -0400

Three points which I hope others also understand the same way I do:

(1) It is possible to have asymmetric flows.  Case 1: one-way flows could be
agreed , so that at one MG only the Local Descriptor is set and at the other
only the Remote Descriptor is set.  Case 2, rather unlikely: the codec
specifications could differ between the Local and Remote Descriptors, both
at MG A and MG B, indicating that each MG is receiving that media stream
using its own codec.

(2) In the negotiation described below, where the Local Descriptor sent out
from MGC A to MGC B had multiple possible codecs, MGC B will select a
specific codec in its return message.  That choice is passed on to MG A by
updating the content of its Local Descriptor.

(3) Where non-RTP terminations are involved, the contents of Local and
Remote Descriptor will typically be assigned by the MGC based on the content
of call signalling.

> From: Brian Rosen [SMTP:[email-masked]]
> Sent: Friday, August 20, 1999 10:06 AM

---

From: Brian Rosen <[email-masked]>
Date: Fri, 20 Aug 1999 11:29:33 -0400

It could very well be me that is confused -- it has happened
several times in this thread :( -- but otherwise, it appears to
be you :)   My view at the moment is:

"Local" is what I can do
"Remote" is what we negotiated we would do

Doesn't have anything to do with flow direction!

Therefore:
Even if you have a one way flow, the local descriptor contains
your proposal for how to do it, and remote contains the
negotiated result of what you both will do.  Let's say you are
the transmitter, and he is the receiver of the one way flow.
You propose G.711, G.726 and G.729 in your local.  He proposes
G.711 and G.729 in his.  The result is G.729.  Your remote (and
his) would specify a one way G.729 codec.

Asymmetric codecs have to work the same way.  I don't recall if
either SDP or H.245 can express such a thing, but if they did,
you would propose it in your local, and the result would be in
your remote.

When we say that the remote contains a negotiated version of
the other local, we probably should reword that to be the
negotiated results of the two proposals.  You have a proposal,
I have a proposal, we negotiate, the result is the SAME.
Thus the two remote descriptors are close to identical (they
aren't really, for example, they have port/address stuff for
the other guy).  You don't normally set the local (you just get
it), and you don't normally inspect the remote, you just set it.

Leads to a minor problem.  How do you make the local descriptor
be returned when you first add the RTP termination?
Something like "...Local{Codec=?}" maybe.  It would be nice to
have some shorthand so that you don't have to underspecify all
the possible parameters in the Add to get a complete capability
list.

I also don't understand point 3.  Suppose that we were
negotiating an ATM AAL2 connection.  You still want to find
out from the MG what codecs it can accommodate (at this time),
and you end up negotiating the profile, so the resulting
profile you use has to be given to the MG.  Your capability is
sent from the MG in local, the result is sent from the MGC in
remote.

At least that is what my addled brain is currently espousing!

Brian

> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Friday, August 20, 1999 10:24 AM

---

From: Brian Rosen <[email-masked]>
Date: Fri, 20 Aug 1999 13:20:59 -0400

I think we are converging.
> ..... "Remote" should
> reflect what the far end can do, filtered through the results of
> negotiation.

Close.  "Remote" should reflect what we both do, filtered through the
results of negotiation to find an intersection.

The fundamental thing is that the settings the MG uses for both sides of the
flow are in remote.  Local has the capability of
what we could do.  The MGC reads local, sets remote.  The word remote works
for me because it describes what the stream sent or received out of the MG
looks like, using the analogy that you describe what the other guy
needs/wants in the RTP termination, and what your end needs/wants in the
other termination (usually a circuit termination), with an implied
conversion in between.

Is there any circumstance where an MGC modifies or sets local
on an RTP stream? I can think of any.

How about the circuit terminations?  What is remote and local there?  If I
get what you are saying, all of its parameters are in local.  Makes more
sense to me if we leave it as local tells you what it could be, remote is
where you specify it.

> Sent: Friday, August 20, 1999 12:49 PM
> Comments below.  I'm concerned to make sure that we can achieve the
> functionality of single-direction and asymmetric media
> streams.  I'm not
> trying to push any particular way of doing it, just make sure
> I understand
> how our chosen method does it.
>
> > From: Brian Rosen [SMTP:[email-masked]]
> > Sent: Friday, August 20, 1999 11:30 AM
> > To:   Taylor, Tom-PT [CAR:B901-I:EXCH];
> > [email-masked]
> > Subject:      RE: T4) rx/tx Descriptor vs local/remote Descriptor
> >
>         [[TomT]]  ...
>
> > "Local" is what I can do
>         [[TomT]]
>         Sauce for the goose is sauce for the gander.  "Remote" should
> reflect what the far end can do, filtered through the results of
> negotiation.  I've tended in my thinking to focus on the
> resources I can
> allocate at my end, which include my receiving port.   That's why I've
> tended to think of "Local" as what I'm prepared to receive,
> but I can see
> that I've been too limited in my thinking -- I could also
> state what I'm
> prepared to send.
>
>         [[TomT]]
>         H.245 can certainly express it, because in its
> natural idiom you
> open one flow at a time.  Bidirectional H.245 logical
> channels are possible
> but not usual practice for voice or video.
>
>         SDP can express it by having two blocks, one for each
> direction.
> One would contain an a=sendonly line, the other an a=recvonly
> line.  These
> are additional to the activity parameter you need in localControl to
> regulate activity from moment to moment within one MG.  The
> need for two SDP
> blocks in this case is why I've suggested in the past that
> the more natural
> descriptor organization is into one part that negotiates what
> you send, the
> other that negotiates what you receive.
> >
> >
>         [[TomT]]  ...
> >
>         [[TomT]]
>         I'd like to hear suggestions on this, but one
> possibility is that
> you don't do it but issue an Audit first if you really want
> to know.  My
> basic thought is that the MGC has a general idea of the
> status of the MG
> resources and can refresh that knowledge only when necessary.
>
>         [[TomT]]
>         Point 3 may have been too broadly put, but was meant
> to address the
> case of SCN-facing terminations.  That's why I'm saying you
> would either get
> your codec indicated as a bearer capability or you'd have to
> detect it.
>

---

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 20 Aug 1999 13:58:42 -0400

Looking good so far.  Now let's consider how the MGC negotiates capabilities
with its own MG.  This has to happen at both ends: MGC A may have
preferences based on call signalling, and MGC B has the combination of local
policy and the Local Descriptor it received from MGC A to worry about.  The
MGC can send its policy envelope in three possible places: localControl,
"Local", or "Remote".  For greatest consistency, I would choose Remote.
That way the behaviour is the same at both ends.  The principle also applies
for circuit connections: the MGC specifies in the Remote descriptor what it
must based on bearer capability in the call signalling.  In any case, the MG
returns a "Local" descriptor filled out with what it can offer within the
policy envelope set by the MGC.  If the descriptor is empty in this
response, the MG cannot provide the service the MGC has asked for.

I'd be tempted to rename "Remote" to "Policy" if we went with this approach.

Staying with Local/Remote terminology for the moment, if Remote at any time
provides the policy envelope which the MGC imposes on the MG, we have a way
to control MG-initiated codec changes.  I suppose before raising this
possibility I should check back on the thread which disposed of that
possibility before.

We need a way for MGC A in particular to say that it imposes no policy
constraint.  How about a wildcard in place of the SDP or H.248 Native
capability block?

> Sent: Friday, August 20, 1999 1:21 PM

---

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 20 Aug 1999 15:02:36 -0400

You can save one round-trip between MGC B and MG B if MG B is able to make
the selection.  Here's how I see it from MGC B's point of view if MGC B
makes the final decision:
 - incoming message from MGC A: specifies capabilities from A's point of
view
 - MGC B sends down something to MG B to ask what it can handle.  This could
either be an ADD with underspecified descriptors or an Audit.  (I would like
to pin down exactly how the ADD is set up if we go this route.)
 - MG B responds with a set of choices
 - MGC B sends an ADD or MODIFY to MG B with its final decision.

If our syntax allowed the MGC to indicate acceptable alternatives (could be
just one) and the MG to return a single selected alternative that second
message to MG B would be unnecessary.  On the other hand, if we assume that
the MGC generally knows in advance what MG B can handle it could make the
choice on the first pass anyway.

> Sent: Friday, August 20, 1999 2:33 PM
> The problem I'm having with this one is that I think that
> the MGC doesn't negotiate with its MG.  It asks the MG
> what it can do.  It applies it's policy, and the result of
> that (which is the intersection of what the MG can do,
> and what the MGC is willing to let it do) is the input to
> capability negotiation with the other MGC.
>
> It will have done the same with its MG, and the intersection of
> those two capability sets will be the possible answers.
>
> Possible Answers =
>   Intersect(
>       Intersect(What MG-A could do,What MGC-A is willing to do),
>       Intersect(What MG-B could do,What MGC-B is willing to do)
>   )
>
> or in other words
>   Negotiate(PolicyOfMGC-A(Capability of MG-A),
>             PolicyOfMGC-B(Capability of MG-B))
>
> The MGC-MGC protocols define how decisions are made when there are more
> than
> one possible choices both sides can do.
> When the MGCs are done, there is one set of settings on
> each side, sent in remote to the respective MGs.
>
> So it seems to me it all works as is: capability in local,
> settings in remote.
>
> At one point we did have the idea that the MGC could send underspecified
> values that were choices, and the MG could choose among them.  We don't
> have
> that any more.  That would be
> kind of a shortcut - policy sent from MGC to MG, result choice returned by
> MG.  It's really the same thing with the MG doing the intersect.
>
> Brian
> >

---

From: Brian Rosen <[email-masked]>
Date: Fri, 20 Aug 1999 15:56:02 -0400

Is this not what fast start does?  I think it should work
in a case where the terminating end chooses from the originating end's
offered list.  It doesn't work (I think) with a full capability negotiation.
So it seems like we should have the
protocol be able to do this, but not require it.

I think it works, in that by using the replicated SDP or the alternative
syntax in "native" you can "underspecify" the remote descriptor.  The MG
would make a choice, and return a fully specified remote descriptor.

Brian

> Sent: Friday, August 20, 1999 3:03 PM

---

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 20 Aug 1999 15:09:54 -0500

Looks like an action on us (me) to make sure we have examples showing
various negotiation possibilities.  Clearly for the full H.245 capability
negotiation case the MGC has to know what the MG can do in advance, probably
by doing an audit.

Sometimes you "underspecify" and sometimes you "over-specify by giving
multiple choices.  You do the former (maybe) when you want to know what the
MG has to offer, the latter when you want it to select from a predetermined
range of choices.  Then there's the case where you truly want to have the MG
pick something and you don't care what.  Do we distinguish this one from the
capability query by using "*" to say "tell me what you can do" and "$" to
say "choose one"?

---

From: Brian Rosen <[email-masked]>
Date: Fri, 20 Aug 1999 16:32:27 -0400

Well, maybe we are in sync, but let me check:

If you use audit, you don't need any syntax; you always get
a full list of what you could do.

When you underspecify, you use "choose" ($), which means, use whatever you
want, I don't care.  The MG responds with its
choice

When you overspecify, you send alternatives, either as replicated
descriptors, or the alternative syntax promised
for "native".  The MG responds with its choice.

Are you proposing "*" for the case where you want to get a return from the
MG using an Add/Move/Modify rather than an Audit?

> Sent: Friday, August 20, 1999 4:10 PM

---

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 23 Aug 1999 10:18:36 -0400

Glad to have another voice in the discussion.  I always have to be
suspicious of the degree of consensus when just two people are involved.

OK, the problem is to understand the respective roles of Local and Remote.
Along the way, hidden under it all, is whether the MGC wants to know the
capabilities of the MG moment by moment and if so, whether it does it by
Audit or by responses to other commands.

As for the roles of Local and Remote: the understanding Brian had and I
accepted, was that both descriptors described media flows in both
directions.  The understanding we reached in discussion was that the MGC
could use Remote to set policy, either by indicating the outcome of
capability negotiations or by providing an ordered set of alternatives from
which the MG could select.  This latter use could conflict with a subtly
different semantic which allows simultaneous or alternating use of different
payload types within a call -- I have in mind the use of the DTMF payload
type alternating with the voice codec.  Regardless of all this, Remote must
also convey the far-end addresses to which the MG must direct its outgoing
media traffic.

This leaves the meaning of Local open for discussion.  In the first place,
it must convey the near-end addresses at which the MG will receive incoming
media traffic.  If the MG has been given a choice of options within Remote,
it can indicate its selection within Local in its response.

As indicated in your message, the awkward part comes if Local is used to
indicate capabilities (where Remote has not set any constraints).  Whatever
questions you have about this procedure apply equally to an Audit performed
in mid-operation.  The main issue is whether Local should be used to
indicate capabilities in the first place, or whether Audits should be the
only mechanism for that purpose.

> From: John Segers [SMTP:[email-masked]]
> Sent: Monday, August 23, 1999 6:31 AM
> Tom, Brian,
> This discussion on terminology is becoming increasingly confusing to
> me.  A while ago, I heard some arguments for Tx/Rx and for
> Local/Remote.  The intention of both was to describe _actual_
> properties/parameters of media streams.  Now we are suddenly saying that
> Local contains capabilities and that Remote contains the actual
> parameters.
>
> Apart from the fact that I find that the names Local and Remote do not
> cover the meaning any more, I have a problem with describing the
> capabilities for a media stream by means of a sub-descriptor of the
> media descriptor.  For instance, does this mean that a Termination that
> can do video always has to have a local descriptor that specifies which
> video parameters are possible?  And what if the use of a certain codec
> influences the capability of using other codecs on other Terminations?
> Does the local descriptor then change?
>
> John
>
> Tom-PT Taylor wrote:
> >
> > functionality of single-direction and asymmetric media streams.  I'm not
> > trying to push any particular way of doing it, just make sure I
> understand
> > negotiation.  I've tended in my thinking to focus on the resources I can
> > tended to think of "Local" as what I'm prepared to receive, but I can
> see
> > that I've been too limited in my thinking -- I could also state what I'm
> > prepared to send.
> >
> >         H.245 can certainly express it, because in its natural idiom you
> > open one flow at a time.  Bidirectional H.245 logical channels are
> possible
> >         SDP can express it by having two blocks, one for each direction.
> > One would contain an a=sendonly line, the other an a=recvonly line.
> These
> > regulate activity from moment to moment within one MG.  The need for two
> SDP
> > blocks in this case is why I've suggested in the past that the more
> natural
> > descriptor organization is into one part that negotiates what you send,
> the
> >         I'd like to hear suggestions on this, but one possibility is
> that
> > you don't do it but issue an Audit first if you really want to know.  My
> > basic thought is that the MGC has a general idea of the status of the MG
> >         Point 3 may have been too broadly put, but was meant to address
> the
> > case of SCN-facing terminations.  That's why I'm saying you would either
> get
> > your codec indicated as a bearer capability or you'd have to detect it.
> >
> --
> John Segers                                  email: [email-masked]
> Lucent Technologies                                        Room HE 306
> Dept. Forward Looking Work                      phone: +31 35 687 4724
> P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954

---

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 24 Aug 1999 09:28:25 -0500

Agreed that H.245 capability negotiation messages would come from and
terminate in the MG.  However, I think our architectural principle, at least
as an option, is that policy constraining these negotiations is set by the
MGC.

I've had a chance to discuss the whole question of the original topic of
this thread with Chip Sharp, face to face at the Sigtran design meeting
we're both attending.  I hope to issue an E-mail confirming our joint
understanding (which is different from what Brian and I worked up on Friday)
later today.  The basic principle is that the LocalControl piece would
contain the policy (i.e. allowed codec alternatives, etc.).

> From: Christian Groves [SMTP:[email-masked]]
> Sent: Tuesday, August 24, 1999 12:01 AM
> I thought that it was still a valid part of the H323 architecture that
> H.245 be terminated in the MG. As such we need to be able to support
> capability negotiation at the MG level in H.248/Megaco. I can also see
> for different scenarios for different applications you may also want the
> logical channel handling in the MG. Having H245 in the MG implies that
> we need some sort of binding information to be carried across H248 to
> tie the Call Control level with the  H.245 (channel id?). This binding
> would also be useful for ATM scenarios.
>
> Cheers, Christian
>
> Tom-PT Taylor wrote:
> >
> > One missing element here is an H.245 event package akin to the H.242
> package
> > you presented in Berlin.  If we define that, we can see how everything
> fits
> > together.  As I see it, the basic principle is that the video control
> stuff
> > should stay down at the MG/MP for local action, while stuff like
> capability
> > negotiation and logical channel handling has to be controlled by the
> MGC.
> >
> > > Sent: Monday, August 23, 1999 5:51 AM
> > > Brian,
> > > We used to have a requirement that it be possible for the MG to
> perform
> > > the H.245 negotiation with the other end.  If the MGC cannot
> communicate
> > > its policy to the MG by means of underspecified values, this doesn't
> > > seem possible anymore.
> > >
> > > John
> > >
> > > Brian Rosen wrote:
> > > [snip]
> > > > kind of a shortcut - policy sent from MGC to MG, result choice
> returned
> > > by
> > > > > Sent: Friday, August 20, 1999 1:59 PM
> > > > > > The fundamental thing is that the settings the MG uses for
> > > > > both sides of
> > > > > > the
> > > > > > what we could do.  The MGC reads local, sets remote.  The
> > > > > word remote
> > > > > > works
> > > > > > > > > (1) It is possible to have asymmetric flows.  Case 1:
> one-way
> > > > > > > > > flows could be
> > > > > > > > > agreed , so that at one MG only the Local Descriptor is
> set
> > > > > > > > > and at the other
> > > > > > > > > at MG A and MG B, indicating that each MG is receiving
> that
> > > > > > > > > media stream
> > > > > > > > > using its own codec.
> > > > > > > > >
> > > > > > > > > specific codec in its return message.  That choice is
> passed
> > > > > > > > > on to MG A by
> > > > > > > > > Remote Descriptor will typically be assigned by the MGC
> based
> > > > > > > > > on the content
> > > > > > > > > of call signalling.
> > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > >
> > >
> > > --