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

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

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

> -----Original Message-----
> From: Tom-PT Taylor [mailto:[email-masked]]
> Sent: Friday, August 20, 1999 1:59 PM
> To: [email-masked]
> Subject: Re: T4) rx/tx Descriptor vs local/remote Descriptor
>
>
> 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?
>
>
>
> > -----Original Message-----
> > From: Brian Rosen [SMTP:[email-masked]]
> > Sent: Friday, August 20, 1999 1:21 PM
> > To:   [email-masked]
> > Subject:      Re: T4) rx/tx Descriptor vs local/remote Descriptor
> >
> > 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.
> >
> > > -----Original Message-----
> > > From: Tom-PT Taylor [mailto:[email-masked]]
> > > Sent: Friday, August 20, 1999 12:49 PM
> > > To: [email-masked]
> > > Subject: Re: T4) rx/tx Descriptor vs local/remote Descriptor
> > >
> > >
> > > 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.
> > >
> > > > -----Original Message-----
> > > > 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
> > > > "Remote" is what we negotiated we would 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.
> > >
> > > > 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.
> > >         [[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]]  ...
> > > >
> > > > 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.
> > >         [[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.
> > >
> > > > 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.
> > >         [[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.
> > >
> > > > At least that is what my addled brain is currently espousing!
> > > >
> > > > Brian
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Tom-PT Taylor [mailto:[email-masked]]
> > > > > Sent: Friday, August 20, 1999 10:24 AM
> > > > > To: [email-masked]
> > > > > Subject: Re: T4) rx/tx Descriptor vs local/remote Descriptor
> > > > >
> > > > >
> > > > > 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: John Segers <[email-masked]>
Date: Mon, 23 Aug 1999 11:50:59 +0200

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]

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