Subject: Re: Proposed Text For Media Specification

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 22 Dec 1999 11:48:19 -0500

Could we take this one step further toward concreteness?  A couple of points
have been bothering me: how does the MG at the originating end know which
alternatives to offer, and at the terminating end what does the MG do with
Remote?  Furthermore, how does the MGC tell the MG: "This is what you're
going to use; we're not negotiating any more."?

I've also realized that unless both send and receive capabilities can be
expressed in the same descriptor, there is no way for the originating MG at
least to express joint capabilities for asymmetric connections.  We may be
able to live without this.  Certainly the H.323 crowd would prefer to do so,
since H.245 and H.323 fastStart both separate capabilities by direction of
flow.

These are my answers to my own questions, starting from the premise that
Local describes received flows, Remote describes transmitted flows.

(1) At the originating end, the MGC may supply a set of alternative session
descriptions (mutually exclusive alternatives) and within each a list of one
or more payload types.  Here's the key point: the MG in its response is
constrained by the list of payload types -- it can't offer any not listed in
the first place by the MGC.  However, it can offer alternatives for detailed
parameters associated with those payload types.  This is especially
necessary with video, where the list of possible alternatives can go on
forever.  We'll have to think a bit about the syntax for offering these
alternatives -- yet more session descriptions or ranges or whatever.

(2) At the terminating end, the MGC takes the signalled send and receive
capabilities from the far end.  (If the signalling is via SDP and
capabilities are not broken out by direction, symmetric flow capabilities
are assumed.)  The terminating MGC may filter out non-starters from its
policy viewpoint, then it will build Local and Remote from what remains.

Now the question is what rule the MG follows to evaluate what is presented.
First off, I assume we want the MG to choose a single alternative at this
point.  How is that indicated by the MGC?  I would favour an explicit
parameter in LocalControl rather than a rule like "If Remote is present,
choose a single alternative rather than presenting alternatives.".

> -----Original Message-----
> From: Rosen, Brian [SMTP:[email-masked]]
> Sent: Wednesday, December 22, 1999 10:46 AM
> To:   Taylor, Tom-PT [CAR:B904-I:EXCH]
> Cc:   Megaco (E-mail)
> Subject:      RE: Proposed Text For Media Specification
>
> In defense of the position I would point out that when the
> MG supplies it's version of local it is BEFORE negotiation
> takes place.  This has to be true because it has to reserve
> resources and report what it could support.  The MGC must take
> that set of alternatives and negotiate with its opposite MGC.
> The result of that negotiation has to be one, agreed upon session
> description that both MGs can support.
>
> Given that, I think the MG must offer a set of alternatives.
>
> Brian
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:[email-masked]]
> > Sent: Wednesday, December 22, 1999 10:40 AM
> > To: Chip Sharp; Brian Rosen; [email-masked]
> > Subject: RE: Proposed Text For Media Specification
> >
> >
> > I'm willing to follow this thought along a bit further.  I think the
> > concrete difference between the viewpoint I've documented and the
> > "policy-capability" viewpoint is this: if the MGC sends down
> > a number of
> > alternative session descriptions, in my case the MG picks
> > one, while in
> > Brian's case the MG replies with all the session descriptions it can
> > currently support.  I am willing to accept the latter
> > proposition if we can
> > all agree on it.  From there, I will go forward with Chip's
> > distinction
> > between the roles of Local and Remote, and I think we'll have a good
> > sensible result.
> >

---

From: John Segers <[email-masked]>
Date: Thu, 23 Dec 1999 09:21:11 +0100

Tom,

Faststart adds a twist to all of this.  If the originating MGC (after
determining MG capabilities) allows multiple options for codec, the
originating MG has to be able to receive media according to any of
these: the far end may choose one of the options presented and start
sending media.  You can't assume that the MGC has the opportunity to
send a Modify to the MG before the first media packets arrive.

In the megaco syntax it should be possible to distinguish between an MGC
telling an MG to "choose one of the options a, b, or c" and "reserve
resources for options a, b, and c".  The former is an MGC enforcing
policy on the local MG, the latter is for support of faststart.  I
assumed that for both cases the MGC already knows what the MG could do.

Cheers,

John

> Tom-PT Taylor wrote:
>
> Could we take this one step further toward concreteness?  A couple of
> points have been bothering me: how does the MG at the originating end
> know which alternatives to offer, and at the terminating end what does
> the MG do with Remote?  Furthermore, how does the MGC tell the MG:
> "This is what you're going to use; we're not negotiating any more."?
>
> I've also realized that unless both send and receive capabilities can
> be expressed in the same descriptor, there is no way for the
> originating MG at least to express joint capabilities for asymmetric
> connections.  We may be able to live without this.  Certainly the
> H.323 crowd would prefer to do so, since H.245 and H.323 fastStart
> both separate capabilities by direction of flow.
>
> These are my answers to my own questions, starting from the premise
> that Local describes received flows, Remote describes transmitted
> flows.
>
> (1) At the originating end, the MGC may supply a set of alternative
> session descriptions (mutually exclusive alternatives) and within each
> a list of one or more payload types.  Here's the key point: the MG in
> its response is constrained by the list of payload types -- it can't
> offer any not listed in the first place by the MGC.  However, it can
> offer alternatives for detailed parameters associated with those
> payload types.  This is especially necessary with video, where the
> list of possible alternatives can go on forever.  We'll have to think
> a bit about the syntax for offering these alternatives -- yet more
> session descriptions or ranges or whatever.
>
> (2) At the terminating end, the MGC takes the signalled send and
> receive capabilities from the far end.  (If the signalling is via SDP
> and capabilities are not broken out by direction, symmetric flow
> capabilities are assumed.)  The terminating MGC may filter out
> non-starters from its policy viewpoint, then it will build Local and
> Remote from what remains.
>
> Now the question is what rule the MG follows to evaluate what is
> presented.  First off, I assume we want the MG to choose a single
> alternative at this point.  How is that indicated by the MGC?  I would
> favour an explicit parameter in LocalControl rather than a rule like
> "If Remote is present, choose a single alternative rather than
> presenting alternatives.".
>

--
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: Bill Foster <[email-masked]>
Date: Thu, 23 Dec 1999 04:05:20 -0800

>assumed that for both cases the MGC already knows what the MG could do.

I don't understand why/how you can separate these. If the MGC wants to find static capabilities it can do an audit but once it starts setting up the call - what value is there in an MG responding with options that it does not have the resources to support?

> >      > between the roles of Local and Remote, and I think we'll have a

-----------------------------
Bill Foster
Phone: (408) 527-8791
Page:   (800) 365-4578
Fax:     (781) 998-6492