Subject: Re: Proposed Text For Media Specification

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 3 Jan 2000 10:23:39 -0500

The "reserve" is worst case resource, not simultaneous.
So if the DSP is already running G.726, and G.723 takes
fewer DSP cycles than G.729, if the MG offers G.726, G.723, G.729,
it would have to reserve enough DSP cycles to do G.729.
We will have to be careful about wording to make this clear.

Brian

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Sunday, January 02, 2000 12:28 PM
> To: Rosen, Brian
> Cc: [email-masked]
> Subject: Re: Proposed Text For Media Specification
>
>
>
> I'm coming in late here, so forgive me if I'm coming
> from left field.
>
> I think that people are missing an important point
> here, if I understand Brian correctly. The MGC
> needs to be able to specify policy both for
> groupings (eg, G.729 + DTMF relay) and choices
> (G.729 or G.711), The MGC should *not*, however,
> tell the MG to prepare itself to receive all of
> those codecs *simultaneously* as the solution to
> the problem.  The reason here is pragmatic: DSP's
> have limited amounts of memory, and many of them
> swap codec code in and out of their fast
> memory. Therefore saying that the DSP must be able
> to simultaneously handle G.729, G.728, G.726 and
> G.711 when that is really a set of "choose one"
> alternatives is going to cause a whole lot of
> implementations to give resource errors instead of
> the desired semantics.
>
>               Mike
>
> Rosen, Brian writes:
>  > Negotiation is always between two MGCs.  Negotiation
> always starts with
>  > capability.  So there is a message
>  > from MGC to MG to ask for capability.  It can express
> policy, but it doesn't
>  > have to.  Then the two MGCs negotiate.
>  > Then both MGCs tell their respective MGs what the result
> is.  One end does
>  > that right away (the end that
>  > decides).  The other end has to wait for the message from
> the distant MGC
>  > before it can tell its MG.  In fast start,
>  > the terminating MG is the decision maker, so it gets
> capability from its MG,
>  > decides based on what it's MG can do, and what the
> originating MGC said the
>  > originating MG can do, and tells it's MG what to do.
>  >
>  > We are bending SDP pretty hard.  Having yet another bend
> so that you can
>  > differentiate between "choose one
>  > of these" and "here is my policy, tell me your capability"
>  is getting
>  > pretty bad.  This is why I liked using
>  > remote and local rather than sendonly or Nancy's vertical
> bar -- less
>  > modification to SDP syntax.
>  >
>  > Brian
>  >
>  > -----Original Message-----
>  > From: Tom-PT Taylor [mailto:[email-masked]]
>  > Sent: Wednesday, December 22, 1999 7:51 PM
>  > To: Rosen, Brian
>  > Cc: [email-masked]
>  > Subject: RE: Proposed Text For Media Specification
>  >
>  >
>  >
>  > I've had to think about this a bit, because I have a
> couple of problems with
>  > it.  The main problem is that there doesn't seem to be any point of
>  > convergence -- the terminating MG sends back its version
> of Local and Remote
>  > to its MGC "and then negotiation occurs" (your words).
> Negotiation between
>  > what entities?  Does there now have to be another round of
> messaging to tell
>  > the MGs what the MGCs have decided, at the terminating end
> as well as at the
>  > originating end?
>  >
>  > Actually, I think I can leave this up to the
> implementation.  We can simply
>  > have a rule that the MG echoes back that subset of
> whatever the MGC proposes
>  > that the MG can support.  If I want to save a message by
> making the final
>  > decision in the terminating MGC BEFORE sending a message
> down to the MG
>  > that's my business as an MGC implementor.
>  >
>  > On your concern about getting capability after policy is
> set: you can always
>  > do an AuditCapability on the termination to start with if
> you want to be
>  > perfect.  The reason the MGC imposes policy has to do with
> the signalling it
>  > has received, or resources it is trying to husband.
> Knowing more precisely
>  > the instantaneous capability of the MG isn't going to
> change those factors.
>  >
>  >         -----Original Message-----
>  > From:   Rosen, Brian [SMTP:[email-masked]]
>  > Sent:   Wednesday, December 22, 1999 3:10 PM
>  > To:     Taylor, Tom-PT [CAR:B904-I:EXCH]
>  > Cc:     [email-masked]
>  > Subject:        RE: Proposed Text For Media Specification
>  >
>  >         In my view each end independently has policy, each
> end independently
>  > has capability.
>  > Each end independently applies policy to capability and
> ends up with an
>  > ordered list
>  > of candidates.  The negotiation is then to select the
> first candidate that
>  > both ends
>  > can support.  This results in a single answer, which is
> communicated to both
>  > sides.
>  >
>  > Suppose the originating MG can do G.711, G.723 and G.729.
>  The policy of
>  > the the MGC
>  > is G.729, then G.726, then G.711, it won't allow G.723.
> Suppose the
>  > terminating end MG has the same capability but the policy
> at its MGC is
>  > G.711 then G.726, then G.729.
>  >
>  >
>  > So the originating MGC sends 729, 726, 711, the
> originating MG responds 729,
>  > 711.
>  > The terminating MGC sends 711, 726, 729, the terminating
> MG responds 711,
>  > 726, 729.
>  > The negotiation occurs.  In this case the negotiation
> would result in 711,
>  > and both
>  > ends would set local and remote to 711.  Note that
> different MGC-MGC
>  > protocols would have different rules on how negotiation
> proceeded, but all
>  > of them would start with an ordered list of possibles,
> eliminate the ones
>  > that only one side can support, and select among the
> remaining ones.
>  >
>  >
>  > I'm a little bothered by the send policy, get capability.  It seems
>  > backwards to me;  if I were
>  > designing the system, I might be inclined to get a
> complete capability,
>  > filter it by policy and
>  > then negotiate the result.  However, the MG has to reserve
> resources for the
>  > worst case of the alternatives it allows.  Therefore, it
> wants to know the
>  > policy so that it does not reserve resources for options
> the MGC would not
>  > allow.  On the other (other) hand, making the
>  >
>  >         MG enforce MGC policy also seems wrong - the MGC
> should enforce it's
>  > own policy.
>  > So, I'd accept the idea that the MG simply states network,
> nothing else, the
>  > MG responds with capability.  The MGC filters that with
> policy, negotiates
>  > it, and then sends the single
>  >
>  >         result to the MG.  The way we have it is okay, and
> as I observe, may
>  > leave the MG with
>  > more available resource.
>  >
>  > Brian
>  >
>  >         -----Original Message-----
>  > From: Tom-PT Taylor [ mailto:[email-masked]
>  > <mailto:[email-masked]> ]
>  > Sent: Wednesday, December 22, 1999 11:48 AM
>  > To: Rosen, Brian
>  > Cc: [email-masked]
>  > Subject: RE: Proposed Text For Media Specification
>  >
>  >
>  >
>  >         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]
>  > <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.
>  > >
>  >
>  > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
>  > <HTML><HEAD>
>  > <META HTTP-EQUIV="Content-Type" CONTENT="text/html;
> charset=iso-8859-1">
>  > <TITLE>RE: Proposed Text For Media Specification</TITLE>
>  >
>  > <META content="MSHTML 5.00.2614.3401" name=GENERATOR></HEAD>
>  > <BODY>
>  > <DIV><FONT color=#0000ff face=Arial size=2><SPAN
>  > class=090593815-23121999>Negotiation is always between two
> MGCs.&nbsp;
>  > Negotiation always starts with capability.&nbsp; So there is a
>  > message</SPAN></FONT></DIV>
>  > <DIV><FONT color=#0000ff face=Arial size=2><SPAN
> class=090593815-23121999>from
>  > MGC to MG to ask for capability.&nbsp; It can express
> policy, but it doesn't
>  > have to.&nbsp; Then the two MGCs negotiate.</SPAN></FONT></DIV>
>  > <DIV><FONT color=#0000ff face=Arial size=2><SPAN
> class=090593815-23121999>Then
>  > both MGCs tell their respective MGs what the result
> is.&nbsp; One end does that
>  > right away (the end that</SPAN></FONT></DIV>
>  > <DIV><FONT color=#0000ff face=Arial size=2><SPAN
>  > class=090593815-23121999>decides).&nbsp; The other end has
> to wait for the
>  > message from the distant MGC before it can tell its
> MG.&nbsp; In fast
>  > start,</SPAN></FONT></DIV>
>  > <DIV><FONT color=#0000ff face=Arial size=2><SPAN
> class=090593815-23121999>the
>  > terminating MG is the decision maker, so it gets
> capability from its MG, decides
>  > based on what it's MG can do, and what the originating MGC
> said the originating
>  > MG can do, and tells it's MG what to do.&nbsp; </SPAN></FONT></DIV>
>  > <DIV><FONT color=#0000ff face=Arial size=2><SPAN
>  > class=090593815-23121999></SPAN></FONT>&nbsp;</DIV>
>  > <DIV><FONT color=#0000ff face=Arial size=2><SPAN
> class=090593815-23121999>We are
>  > bending SDP pretty hard.&nbsp; Having yet another bend so
> that you can
>  > differentiate between "choose one</SPAN></FONT></DIV>
>  > <DIV><FONT color=#0000ff face=Arial size=2><SPAN
> class=090593815-23121999>of
>  > these" and "here is my policy, tell me your
> capability"&nbsp; is getting pretty
>  > bad.&nbsp; This is why I liked using</SPAN></FONT></DIV>
>  > <DIV><FONT color=#0000ff face=Arial size=2><SPAN
> class=090593815-23121999>remote
>  > and local rather than sendonly or Nancy's vertical bar --
> less modification to
>  > SDP syntax.</SPAN></FONT></DIV>
>  > <DIV><FONT color=#0000ff face=Arial size=2><SPAN
>  > class=090593815-23121999></SPAN></FONT>&nbsp;</DIV>
>  > <DIV><FONT color=#0000ff face=Arial size=2><SPAN
>  > class=090593815-23121999>Brian</SPAN></FONT></DIV>
>  > <BLOCKQUOTE
>  > style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px;
> PADDING-LEFT: 5px">
>  >   <DIV align=left class=OutlookMessageHeader dir=ltr><FONT
> face=Tahoma
>  >   size=2>-----Original Message-----<BR><B>From:</B> Tom-PT Taylor
>  >   [mailto:[email-masked]]<BR><B>Sent:</B>
> Wednesday, December 22,
>  >   1999 7:51 PM<BR><B>To:</B> Rosen, Brian<BR><B>Cc:</B>
>  >   [email-masked]<BR><B>Subject:</B>
> RE: Proposed Text For
>  >   Media Specification<BR><BR></DIV></FONT>
>  >   <P><FONT color=#0000ff face=Arial size=2>I've had to
> think about this a bit,
>  >   because I have a couple of problems with it.&nbsp; The
> main problem is that
>  >   there doesn't seem to be any point of convergence -- the
> terminating MG sends
>  >   back its version of Local and Remote to its MGC "and
> then negotiation occurs"
>  >   (your words).&nbsp; Negotiation between what
> entities?&nbsp; Does there now
>  >   have to be another round of messaging to tell the MGs
> what the MGCs have
>  >   decided, at the terminating end as well as at the
> originating end?</FONT></P>
>  >   <P><FONT color=#0000ff face=Arial size=2>Actually, I
> think I can leave this up
>  >   to the implementation.&nbsp; We can simply have a rule
> that the MG echoes back
>  >   that subset of whatever the MGC proposes that the MG can
> support.&nbsp; If I
>  >   want to save a message by making the final decision in
> the terminating MGC
>  >   BEFORE sending a message down to the MG that's my
> business as an MGC
>  >   implementor.</FONT></P>
>  >   <P><FONT color=#0000ff face=Arial size=2>On your concern
> about getting
>  >   capability after policy is set: you can always do an
> AuditCapability on the
>  >   termination to start with if you want to be
> perfect.&nbsp; The reason the MGC
>  >   imposes policy has to do with the signalling it has
> received, or resources it
>  >   is trying to husband.&nbsp; Knowing more precisely the
> instantaneous
>  >   capability of the MG isn't going to change those
> factors.</FONT></P>
>  >   <UL>
>  >     <P><FONT face=Arial size=1>-----Original
> Message-----</FONT> <BR><B><FONT
>  >     face=Arial size=1>From:&nbsp;&nbsp;</FONT></B> <FONT face=Arial
>  >     size=1>Rosen, Brian [SMTP:[email-masked]]</FONT>
> <BR><B><FONT face=Arial
>  >     size=1>Sent:&nbsp;&nbsp;</FONT></B> <FONT face=Arial
> size=1>Wednesday,
>  >     December 22, 1999 3:10 PM</FONT> <BR><B><FONT face=Arial
>  >     size=1>To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT face=Arial
>  >     size=1>Taylor, Tom-PT [CAR:B904-I:EXCH]</FONT>
> <BR><B><FONT face=Arial
>  >     size=1>Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT face=Arial
>  >     size=1>[email-masked]</FONT>
> <BR><B><FONT face=Arial
>  >
> size=1>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FON
> T></B> <FONT
>  >     face=Arial size=1>RE: Proposed Text For Media
> Specification</FONT> </P>
>  >     <P><FONT color=#0000ff face=Arial size=2>In my view
> each end independently
>  >     has policy, each end independently has
> capability.</FONT> <BR><FONT
>  >     color=#0000ff face=Arial size=2>Each end independently
> applies policy to
>  >     capability and ends up with an ordered list</FONT>
> <BR><FONT color=#0000ff
>  >     face=Arial size=2>of candidates.&nbsp; The negotiation
> is then to select the
>  >     first candidate that both ends</FONT> <BR><FONT
> color=#0000ff face=Arial
>  >     size=2>can support.&nbsp; This results in a single
> answer, which is
>  >     communicated to both sides.</FONT> <BR><FONT
> face=Arial>&nbsp;</FONT>
>  >     <BR><FONT color=#0000ff face=Arial size=2>Suppose the
> originating MG can do
>  >     G.711, G.723 and G.729.&nbsp;&nbsp; The policy of the
> the MGC</FONT>
>  >     <BR><FONT color=#0000ff face=Arial size=2>is G.729,
> then G.726, then G.711,
>  >     it won't allow G.723.&nbsp; Suppose the terminating
> end MG has the same
>  >     capability but the policy at its MGC is G.711 then G.726, then
>  >     G.729.</FONT></P>
>  >     <P><FONT face=Arial>&nbsp;</FONT> <BR><FONT
> color=#0000ff face=Arial
>  >     size=2>So the originating MGC sends 729, 726, 711, the
> originating MG
>  >     responds 729, 711.</FONT> <BR><FONT color=#0000ff
> face=Arial size=2>The
>  >     terminating MGC sends 711, 726, 729, the terminating
> MG responds 711, 726,
>  >     729.</FONT> <BR><FONT color=#0000ff face=Arial
> size=2>The negotiation
>  >     occurs.&nbsp; In this case the negotiation would
> result in 711, and
>  >     both</FONT> <BR><FONT color=#0000ff face=Arial
> size=2>ends would set local
>  >     and remote to 711.&nbsp; Note that different MGC-MGC
> protocols would have
>  >     different rules on how negotiation proceeded, but all
> of them would start
>  >     with an ordered list of possibles, eliminate the ones
> that only one side can
>  >     support, and select among the remaining ones.</FONT></P>
>  >     <P><FONT face=Arial>&nbsp;</FONT> <BR><FONT
> color=#0000ff face=Arial
>  >     size=2>I'm a little bothered by the send policy, get
> capability.&nbsp; It
>  >     seems backwards to me;&nbsp; if I were</FONT>
> <BR><FONT color=#0000ff
>  >     face=Arial size=2>designing the system, I might be
> inclined to get a
>  >     complete capability, filter it by policy and</FONT>
> <BR><FONT color=#0000ff
>  >     face=Arial size=2>then negotiate the result.&nbsp;
> However, the MG has to
>  >     reserve resources for the worst case of the
> alternatives it allows.&nbsp;
>  >     Therefore, it&nbsp;wants to know the policy so that it
> does not reserve
>  >     resources for options the MGC would not allow.&nbsp;
> On the other (other)
>  >     hand, making the</FONT></P>
>  >     <P><FONT color=#0000ff face=Arial size=2>MG enforce
> MGC policy also seems
>  >     wrong - the MGC should enforce it's own policy.</FONT>
> <BR><FONT
>  >     color=#0000ff face=Arial size=2>So, I'd accept the
> idea that the MG simply
>  >     states network, nothing else, the MG responds with
> capability.&nbsp; The MGC
>  >     filters that with policy, negotiates it, and then sends the
>  > single</FONT></P>
>  >     <P><FONT color=#0000ff face=Arial size=2>result to the
> MG.&nbsp; The way we
>  >     have it is okay, and as I observe, may leave the MG
> with</FONT> <BR><FONT
>  >     color=#0000ff face=Arial size=2>more available
> resource.</FONT> <BR><FONT
>  >     face=Arial>&nbsp;</FONT> <BR><FONT color=#0000ff face=Arial
>  >     size=2>Brian</FONT> </P>
>  >     <UL>
>  >       <P><FONT face=Tahoma size=2>-----Original
> Message-----<BR></FONT><B><FONT
>  >       face=Tahoma size=2>From:</FONT></B><FONT face=Tahoma
> size=2> Tom-PT Taylor
>  >       [<U></U></FONT><U><FONT color=#0000ff face=Tahoma size=2><A
>  >
> href="mailto:[email-masked]">mailto:taylor@nortelne
> tworks.com</A></FONT></U><FONT
>  >       face=Tahoma size=2>]<BR></FONT><B><FONT face=Tahoma
>  >       size=2>Sent:</FONT></B><FONT face=Tahoma size=2>
> Wednesday, December 22,
>  >       1999 11:48 AM<BR></FONT><B><FONT face=Tahoma
> size=2>To:</FONT></B><FONT
>  >       face=Tahoma size=2> Rosen, Brian<BR></FONT><B><FONT
> face=Tahoma
>  >       size=2>Cc:</FONT></B><FONT face=Tahoma size=2>
>  >
> [email-masked]<BR></FONT><B><FONT face=Tahoma
>  >       size=2>Subject:</FONT></B><FONT face=Tahoma size=2>
> RE: Proposed Text For
>  >       Media Specification<BR><BR></FONT></P>
>  >       <P><FONT color=#0000ff face=Arial size=2>Could we
> take this one step
>  >       further toward concreteness?&nbsp; 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?&nbsp;
>  >       Furthermore, how does the MGC tell the MG: "This is
> what you're going to
>  >       use; we're not negotiating any more."?</FONT></P>
>  >       <P><FONT color=#0000ff face=Arial size=2>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.&nbsp;
> We may be able to
>  >       live without this.&nbsp; Certainly the H.323 crowd
> would prefer to do so,
>  >       since H.245 and H.323 fastStart both separate
> capabilities by direction of
>  >       flow.</FONT></P>
>  >       <P><FONT color=#0000ff face=Arial size=2>These are
> my answers to my own
>  >       questions, starting from the premise that Local
> describes received flows,
>  >       Remote describes transmitted flows.</FONT> </P>
>  >       <P><FONT color=#0000ff face=Arial size=2>(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.&nbsp; 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.&nbsp; However, it can offer
> alternatives for detailed
>  >       parameters associated with those payload
> types.&nbsp; This is especially
>  >       necessary with video, where the list of possible
> alternatives can go on
>  >       forever.&nbsp; We'll have to think a bit about the
> syntax for offering
>  >       these alternatives -- yet more session descriptions
> or ranges or
>  >       whatever.</FONT></P>
>  >       <P><FONT color=#0000ff face=Arial size=2>(2) At the
> terminating end, the
>  >       MGC takes the signalled send and receive
> capabilities from the far
>  >       end.&nbsp; (If the signalling is via SDP and
> capabilities are not broken
>  >       out by direction, symmetric flow capabilities are
> assumed.)&nbsp; The
>  >       terminating MGC may filter out non-starters from its
> policy viewpoint,
>  >       then it will build Local and Remote from what
> remains.</FONT></P>
>  >       <P><FONT color=#0000ff face=Arial size=2>Now the
> question is what rule the
>  >       MG follows to evaluate what is presented.&nbsp;
> First off, I assume we
>  >       want the MG to choose a single alternative at this
> point.&nbsp; How is
>  >       that indicated by the MGC?&nbsp; 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.".</FONT></P><BR><BR>
>  >       <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT
> face=Arial
>  >       size=1>-----Original Message-----</FONT><FONT
>  >       face=Arial><BR></FONT><B><FONT face=Arial
>  >       size=1>From:&nbsp;&nbsp;</FONT></B><FONT face=Arial>
> </FONT><FONT
>  >       face=Arial size=1>Rosen, Brian
> [SMTP:[email-masked]]</FONT><FONT
>  >       face=Arial><BR></FONT><B><FONT face=Arial
>  >       size=1>Sent:&nbsp;&nbsp;</FONT></B><FONT face=Arial>
> </FONT><FONT
>  >       face=Arial size=1>Wednesday, December 22, 1999 10:46
> AM</FONT><FONT
>  >       face=Arial><BR></FONT><B><FONT face=Arial
>  >       size=1>To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B><FONT
> face=Arial>
>  >       </FONT><FONT face=Arial size=1>Taylor, Tom-PT
>  >       [CAR:B904-I:EXCH]</FONT><FONT
> face=Arial><BR></FONT><B><FONT face=Arial
>  >       size=1>Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B><FONT
> face=Arial>
>  >       </FONT><FONT face=Arial size=1>Megaco (E-mail)</FONT><FONT
>  >       face=Arial><BR></FONT><B><FONT face=Arial
>  >
> size=1>Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FON
> T></B><FONT
>  >       face=Arial> </FONT><FONT face=Arial size=1>RE:
> Proposed Text For Media
>  >       Specification</FONT><FONT face=Arial> </FONT></P>
>  >       <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT
> face=Arial size=2>In
>  >       defense of the position I would point out that when
> the</FONT><FONT
>  >       face=Arial><BR></FONT><FONT face=Arial size=2>MG
> supplies it's version of
>  >       local it is BEFORE negotiation</FONT><FONT
> face=Arial><BR></FONT><FONT
>  >       face=Arial size=2>takes place.&nbsp; This has to be
> true because it has to
>  >       reserve</FONT><FONT face=Arial><BR></FONT><FONT face=Arial
>  >       size=2>resources and report what it could
> support.&nbsp; The MGC must
>  >       take</FONT><FONT face=Arial><BR></FONT><FONT
> face=Arial size=2>that set of
>  >       alternatives and negotiate with its opposite MGC.</FONT><FONT
>  >       face=Arial><BR></FONT><FONT face=Arial size=2>The
> result of that
>  >       negotiation has to be one, agreed upon session</FONT><FONT
>  >       face=Arial><BR></FONT><FONT face=Arial
> size=2>description that both MGs
>  >       can support.</FONT><FONT face=Arial> </FONT></P>
>  >       <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT
> face=Arial
>  >       size=2>Given that, I think the MG must offer a set of
>  >       alternatives.</FONT><FONT face=Arial> </FONT></P>
>  >       <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT
> face=Arial
>  >       size=2>Brian</FONT><FONT face=Arial><BR></FONT><FONT
> face=Arial
>  >       size=2>&gt; -----Original Message-----</FONT><FONT
>  >       face=Arial><BR></FONT><FONT face=Arial size=2>&gt;
> From: Tom-PT Taylor
>  >       [</FONT><U><FONT color=#0000ff face=Arial size=2> &lt;<A
>  >
> href="mailto:[email-masked]">mailto:taylor@nortelne
> tworks.com</A>&gt;</FONT></U><FONT
>  >       face=Arial size=2>]</FONT><FONT
> face=Arial><BR></FONT><FONT face=Arial
>  >       size=2>&gt; Sent: Wednesday, December 22, 1999 10:40
> AM</FONT><FONT
>  >       face=Arial><BR></FONT><FONT face=Arial size=2>&gt;
> To: Chip Sharp; Brian
>  >       Rosen; [email-masked]</FONT><FONT
>  >       face=Arial><BR></FONT><FONT face=Arial size=2>&gt;
> Subject: RE: Proposed
>  >       Text For Media Specification</FONT><FONT
> face=Arial><BR></FONT><FONT
>  >       face=Arial size=2>&gt;</FONT><BR><FONT face=Arial
>  >       size=2>&gt;</FONT><BR><FONT face=Arial size=2>&gt;
> I'm willing to follow
>  >       this thought along a bit further.&nbsp; I think
> the</FONT><FONT
>  >       face=Arial><BR></FONT><FONT face=Arial size=2>&gt;
> concrete difference
>  >       between the viewpoint I've documented and the</FONT><FONT
>  >       face=Arial><BR></FONT><FONT face=Arial size=2>&gt;
> "policy-capability"
>  >       viewpoint is this: if the MGC sends
> down</FONT><BR><FONT face=Arial
>  >       size=2>&gt; a number of</FONT><FONT
> face=Arial><BR></FONT><FONT face=Arial
>  >       size=2>&gt; alternative session descriptions, in my
> case the MG
>  >       picks</FONT><BR><FONT face=Arial size=2>&gt; one,
> while in</FONT><FONT
>  >       face=Arial><BR></FONT><FONT face=Arial size=2>&gt;
> Brian's case the MG
>  >       replies with all the session descriptions it can</FONT><FONT
>  >       face=Arial><BR></FONT><FONT face=Arial size=2>&gt; currently
>  >       support.&nbsp; I am willing to accept the
> latter</FONT><BR><FONT
>  >       face=Arial size=2>&gt; proposition if we can</FONT><FONT
>  >       face=Arial><BR></FONT><FONT face=Arial size=2>&gt;
> all agree on it.&nbsp;
>  >       From there, I will go forward with
> Chip's</FONT><BR><FONT face=Arial
>  >       size=2>&gt; distinction</FONT><FONT
> face=Arial><BR></FONT><FONT face=Arial
>  >       size=2>&gt; between the roles of Local and Remote,
> and I think we'll have
>  >       a good</FONT><FONT face=Arial><BR></FONT><FONT
> face=Arial size=2>&gt;
>  >       sensible result.</FONT><FONT
> face=Arial><BR></FONT><FONT face=Arial
>  >       size=2>&gt;</FONT> </P></UL></UL></BLOCKQUOTE></BODY></HTML>
>

---

From: Michael Thomas <[email-masked]>
Date: Mon, 3 Jan 2000 08:31:09 -0800

> We will have to be careful about wording to make this clear.

  I think you're missing my point. It's not just
  CPU cycles, it's memory too. In order to simultaneously
  decode all of the proposed coders, you need them loaded
  into memory. That's a bad assumption. What the semantics
  here really want to be is "I'm willing to load any one
  of these once you choose" or "I've loaded this one, but am
  willing to load these others if you can't support it."

             Mike