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

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 20 Aug 1999 12:48:54 -0400

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 12:31:07 +0200

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

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