Subject: Re: Proposed Text For Media Specification

From: Michael Thomas <[email-masked]>
Date: Sun, 2 Jan 2000 09:28:03 -0800

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;</FONT></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:[email-masked]</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;</FONT></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:[email-masked]</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: Sun, 2 Jan 2000 11:47:24 -0800

As you mention, SDP does not have the ability to
specify choices as it is currently instantiated.
Until that changes, I suggest we live with the
redundancy.

Have I mentioned recently that the use of multiple
SDP's to specify alternatives is going to lead to
combinatorial explosion? Codecs are not the only
thing that we may want to negotiate, after all. In
packetcable, cipher suites are negotiated as well.

                Mike

Rosen, Brian writes:
 > Yes, several of us have been discussing this.
 >
 > It stems from the prior paradigm where:
 > 1. The MGC sent policy to the MG in localcontrol
 > 2. The MG sent capability to the MGC in local
 > 3. The MGC sent negotiated decision to the MG in local
 >
 > To do this, it is necessary to duplicate all the parameters you
 > might have policy and/or capability in both local and localcontrol.
 > This is silly.  So Tom proposed that we change the sequence
 > to:
 > 1. The MGC sends policy to the MG in local
 > 2. The MG sent capability to the MGC in local
 > 3. The MGC sent negotiated decision to the MG in local
 > Restricting all the policy/capability parameters to local.
 >
 > It means a change to the SDP that the MG/MGC exchange to allow
 > specification of choice, and also to deal with asymmetric parameters
 > that H.245 can express.
 >
 > Brian
 > > From: Chip Sharp [mailto:[email-masked]]
 > > Sent: Wednesday, December 22, 1999 1:12 AM
 > > To: [email-masked]
 > > Subject: Re: Proposed Text For Media Specification
 > >
 > >
 > > This would totally change the operation of H.248 from the
 > > current operation
 > > in which the MGC never sends a Local Descriptor.  Sounds like
 > > you want to
 > > use Local Descriptor to send commands to the MG.
 > >
 > > Chip
 > >
 > > At 09:26 PM 12/21/99 -0500, Tom-PT Taylor wrote:
 > > >I am proposing the following changes to section 7.1.8 "Local
 > > and Remote
 > > >Descriptors", in line with the apparent agreement of the WG
 > > that aside from
 > > >purely local matters the MGC should assert its control over
 > > media via the
 > > >Local and Remote descriptors.
 > > >
 > > >Delete the second paragraph entirely.
 > > >
 > > >Replace it with the following text:
 > > >
 > > ><Begin replacement text>
 > > >
 > > >The Local descriptor reserves resources on the local MG for
 > > media reception.
 > > >The following rules apply to the use of the Local Descriptor:
 > > >
 > > >(1) Each session description contained within the Local
 > > Descriptor specifies
 > > >an alternative which the MG may use for encoding and
 > > decoding the given
 > > >stream.  The MG must choose a single alternative from
 > > amongst those offered.
 > > >
 > > >(2) Any one session description MUST contain either one or
 > > two media-level
 > > >descriptions.  If there are two media-level descriptions,
 > > one applies to
 > > >received media (media decoding), the other to transmitted
 > > media (media
 > > >encoding).  The direction of media flow for a given media
 > > description is
 > > >indicated by the presence of the "a=recvonly" or
 > > "a=sendonly" attribute
 > > >respectively, or the Annex C equivalent.  If there is just
 > > one media-level
 > > >description, it MAY contain a directionality attribute; if
 > > it does not, the
 > > >media flow is assumed to be symmetric.  A media-level
 > > description pertaining
 > > >to an
 > > >
 > > >(3) Within any session description, the MGC may use the UNSPECIFIED
 > > >placeholder [proposed to be "-" for text encoding] to
 > > indicate a parameter
 > > >value which can only be assigned by the remote device.  The
 > > MG must search
 > > >for the corresponding value within the Remote Descriptor and
 > > substitute its
 > > >value.  It is an error for the MGC to enable a flow in
 > > either direction
 > > >(through its setting of the Mode parameter in LocalControl)
 > > before all
 > > >UNSPECIFIED values have been resolved.  Upon detection of
 > > such an error the
 > > >MG must reject the transaction and return the error
 > > indication 441, "Missing
 > > >RemoteDescriptor".
 > > >
 > > >(4) Within the session description which the MG chooses to
 > > support, if
 > > >multiple media encodings are specified, the MG must reserve
 > > the resources to
 > > >handle all of them.  To be more specific, it must reserve
 > > resources in
 > > >accordance with the following assumptions:
 > > >  - for transmitted media content the encodings are listed
 > > in decreasing
 > > >order of preference.  If a given encoding is applicable only
 > > to a subset of
 > > >media content (e.g. the new tones payload type) then less-preferred
 > > >encodings will also be used as required to process the outgoing flow.
 > > >  - for received media content, the incoming flow may switch
 > > at any time
 > > >between any of the specified encodings.
 > > >
 > > >(5) The MGC may use the CHOOSE wildcard in place of most
 > > parameter values,
 > > >with the specific exception of network type and medium type.
 > >  (Network type
 > > >MUST always be the same as that indicated in the Network
 > > Type property in
 > > >TerminationState.  Depending on the implementation, the MG
 > > will require that
 > > >the medium type for a given stream be the same for all
 > > terminations in the
 > > >same context, or may allow certain implicit transformations such as
 > > >text-to-voice.)  The MG is free to assign any value to the
 > > wildcarded item
 > > >which is consistent with the remainder of the media
 > > description.  It must
 > > >return the Local Descriptor with the assigned values in its response.
 > > >
 > > >(6) If the MG is unable to reserve sufficient resources to
 > > support any of
 > > >the offered alternatives it must reject the transaction,
 > > returning error
 > > >510, "Insufficient resources".
 > > >
 > > >(7) If the MG successfully reserves resources for one of the offered
 > > >alternatives, and the Local Descriptor originally supplied
 > > by the MGC was
 > > >under-specified either through use of the CHOOSE wildcard or through
 > > >omission of attributes for which the MG is able to supply
 > > default values,
 > > >the MG must return a completed Local Descriptor in its
 > > response, showing the
 > > >values which it has supplied.  This may require the use of
 > > one or more
 > > >"a=fmtp..." attribute lines or the Annex C equivalent to
 > > show additional
 > > >format parameters individually for each media encoding
 > > within the session
 > > >description.
 > > >
 > > >The Remote Descriptor describes resources reserved in the
 > > remote device.
 > > >The MGC may initially omit the Remote Descriptor, but must
 > > ensure that any
 > > >UNSPECIFIED values are resolved before the affected flows
 > > are activated, as
 > > >mentioned in rule (3) above.  It is an error for the MGC to specify
 > > >inconsistent Local and Remote Descriptors.  If the MG
 > > detects such an error
 > > >it must reject the transaction, returning error ??? [need one].
 > > >
 > > >The MG uses the Remote Descriptor for two purposes:
 > > >  - to resolve any UNSPECIFIED values present in the Local Descriptor
 > > >  - to add details of specification (such as additional
 > > attribute values for
 > > >a given encoding) which are not present in the Local
 > > Descriptor provided by
 > > >the MGC.
 > > >It is possible that the additional detail provided by the
 > > Remote Descriptor
 > > >creates a configuration which cannot be supported by the MG,
 > > even though it
 > > >can support the Local Descriptor.  In this case, as in rule
 > > (6) above, the
 > > >MG rejects the transaction with error 510, "Insufficient resources".
 > > >
 > > ><End of replacement text>
 > > >
 > > >Tom Taylor
 > > >Advisor -- IPConnect Standards
 > > >E-mail: [email-masked] (internally, Tom-PT Taylor)
 > > >Phone and FAX: +1 613 736 0961
 > >
 > > Support NetAid!  http://www.netaid.org
 > > --------------------------------------------------
 > > Chip Sharp                 Consulting Engineering
 > > Cisco Systems              Telco Bio-region
 > > Reality - Love it or Leave it.
 > > --------------------------------------------------
 > >
 >
 >

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 3 Jan 2000 11:46:14 -0500

The requirement would be that the MG reserve enough memory to
support ANY, not ALL.  So, if the G.723 codec was the biggest
memory hog, but the G.729 was the biggest cycle hog, the MG
would have to reserve enough memory for .723, and enough cycles
for .729.  If there were any other resources, it would have to
do a similar thing - reserve enough resources so that it can
support any of the options it offers.

Brian

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Monday, January 03, 2000 11:31 AM
>  > 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.
>
>   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
>

---

From: Michael Thomas <[email-masked]>
Date: Mon, 3 Jan 2000 10:47:20 -0800

Tom-PT Taylor writes:
 > "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
 > 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

   Aside from the issue of not wanting to recreate
   syntax when you could use SDP to do the same,
   there are three constraints which we must adhere
   to:

   1) Negotiation must happen with a three way handshake
      between the MGC and the two MG's: eg Add(o)/Add(t)/Modify(o)
      I think that Tom's original proposal does not meet this
      requirement, though Brian's does.

   2) MG's which offer the set of codec alternatives in
      Brian's proposal MUST NOT be expected to have those
      coders actually loaded and prepared to process media
      packets. The MG will only prepare itself for receipt
      of packets when it sees a single choice.

   3) The entire process MUST NOT lead to front end clipping.
      I'm not sure how you do this given the other constraints
      other than making it into a 4 way handshake. Maybe somebody
      more clever than me can solve that problem.

                  Mike

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Mon, 3 Jan 2000 15:22:25 -0500

Brian,

[We need a FastStart expert here ... but ... I think
that you got it "almost" right].

When FastStart succeeds, any early media toward the
originator will have a RTP codec type that you "expect",
thus you can happily decode before receiving the modify.
(You expect the modify to correspond to the codec
type that you sent as a choice, including any dynamically
assigned codec types).

But FastStart is allowed to fail (in my limited understanding
of the spec) .... for example the originator requests codec A, B,
or C and the receiver cannot use A, B, or C ... but desires D, E,
or F. In this case the RTP header may or may not provide
sufficient information for you to determine the codec type
(if a static codec type was chosen, you could know).

For the dynamic codec type case the originator must wait for the
result of the (normal, non-FastStart) codec negotiation to complete
to know what it can encode with. Is this correct?

If so, can receiver with "early media" code with D, E, or F (I
don't think so) .... or does it wait until the full outcome of the
codec negotiation process before sending any media (I think this).

[Jim Toga or Dale Skran where are you? ... copying you
both on this].

Michael Ramalho

At 02:17 PM 1/3/00 -0500, Rosen, Brian wrote:
>Well at least one more person is as confused as I am about how
>fast start works.
>
>I assume that if you get media before you get the MGC message that
>tells you what was negotiated, you look at the RTP header to figure out what
>format the data is in, and start decoding.  Is that right?
>
>If true, it means if you see media before the modify, then you
>start decoding, and if the modify says something different than
>you implied from the header, it's an error.  It isn't necessary to
>wait until you get the modify before you can process the media.
>I suppose that since there is the possibility of asymmetric coding,
>you can't send any media until you have the modify.
>
>Anyway, I agree, 3 commands, the original add, which might have
>policy, who's response is capability, the add to the terminating
>MG, which responds with it's (single) choice, and the modify that at the
>originating MG that tells it the single negotiated result.
>
>HOWEVER, this means we need syntax to differentiate between an
>add with policy, respond with capability, and add with policy,
>choose one and respond with your choice.
>
>Brian
>
>> Sent: Monday, January 03, 2000 1:47 PM

Michael A. Ramalho, Ph.D.
Cisco Systems
1802 Rue de la Port
Wall Township, NJ 07719-3784
Office email: [email-masked]
Personal email: [email-masked]
Office: +1.732.449.5762
Cell: +1.732.809.0188
Pager: +1.800.365.4578

---

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 4 Jan 2000 09:08:07 -0500

I can accept this description of the process.  To recap a key point: an MG
knows it has to select a single alternative when it receives a non-empty
Remote.  Otherwise it returns Local minus whatever it couldn't allocate
resources for.

Now some syntactic nits:

(1) Can the MG return more detail than the MGC provided?  I'm thinking
particularly of video, with its many parameters, but I suppose it could also
happen with audio.

(2) Does each new setting of Local completely replace whatever was set on
that termination for that stream previously, or can some parameters be set
in advance and respecified only as required?  I would suggest complete
replacement, because we are otherwise led further into the murky depths of
SDP syntax enhancement.

(3) What is the meaning of an empty descriptor when sent from the MGC to the
MG?  when sent from the MG to the MGC?

(4) We have already (per the opening paragraph of this note) ascribed
meaning to a missing Remote Descriptor in a command from the MGC to the MG.
In what other cases may a Local or Remote descriptor be absent?

(5) Do we accept the distinction between simultaneous resource commitments
(be prepared to accept/apply any of these at any time) vs. mutually
exclusive commitments (reserve resources to handle any one of these
possibilities, but in the end we'll commit to just one)?  Do we accept that
simultaneous commitments are described within a single media session
description, while mutually exclusive commitments are described in separate
session descriptions?

> From: Rosen, Brian [SMTP:[email-masked]]
> Sent: Tuesday, January 04, 2000 8:28 AM
> To:   [email-masked]
> I think buffering is going to be needed if you are encrypting.
> The real question is whether you always have to do this, or there
> is some way to know if you might be.
>
> The syntax problem is pretty much a "local" thing.  On the originating
> end,
> you want to ask for capability.  On the terminating end, you want to ask
> the
> MG to make a choice.  In both cases, it's local that this happens in.  The
> other end gets the result (the return from the add) as its remote.
>
> The following is more detail than you need, but I thought I'd
> write down how I think it works in great detail for others
> to decide if they agree, or have a different view:
>
> More specifically, the originating end gets the terminating
> end's local as its remote, while the terminating end gets a
> negotiated version of the originating end's local as its remote).
> Working this out a little more, the originating MGC, having no idea what
> the
> terminating side wants, has only its local policy. It puts this in local
> in
> the first Add.  The originating MG filters this (takes out what it can't
> do), reserving worst case resources, and
> returns this filtered version of local in the response to the Add.
> There is no remote at all in this Add, because the originating MGC
> doesn't know any part of what goes in remote.
>
> The originating MGC sends this to the terminating MGC.  The terminating MG
> filters the received proposal with its policy,
> and sends it in remote.  If it will allow asymmetric coding (unusual)
> it could just send its policy in local, but in most cases, it will
> just present the same coding options it got from the originating
> end, filtered by it's policy (which could be reordering, as well
> as removing options) in local.
>
> The terminating MG gets the choices and chooses one for local and
> remote (usually the same, could be different) if it can and returns
> the single chosen value in the reply to its add.  If it cannot,
> it means none of the offered choices are acceptable.  In that case
> it must return an error.  The response to this error might be
> to attempt the Add again with just the terminating end's policy,
> which would be returned, and then the terminating end can propose
> those choices in a full (non fast start) negotiation.
> Assuming success, the terminating MGC returns the choice to the
> originating
> MGC, which modifies the termination, both in local and
> remote.
>
> As with the prior discussion, this means local has what you send,
> and remote has what you receive (which is what the other end sends).
>
> You see the syntax issue in local?  The originating MG sees an
> Add with an overspecified local, but returns an overspecified local.
> The terminating MG sees an Add with an overspecified local but
> returns a fully specified local.  The originating MG doesn't get
> a remote with the add.  The terminating MG sees an overspecified remote
> which it returns fully specified.
>
> Brian
>
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 4 Jan 2000 11:08:11 -0500

> (3) (for clarification)  If a MGC supplies one fully specified (local)
> descriptor, the MG's reply will not contain that descriptor
> (as opposed
> to an empty descriptor being sent from MG to MGC).
Right.  No reason to, and it fits the current behavior (no response to fully
specified descriptors)

> (4) Remote without local may occur in case a one way stream
> is being set
> up.  The MG doesn't have to be prepared to receive anything, it will
> only send media.
Okay, good point.  So it's legal, not an error.

> (5) I don't quite understand Tom's question either.
>
> Earlier in the thread there was discussion about which
> descriptor to use
> in the first Add on the originating side.  Is Local used, or
> LocalControl?  I don't think it was resolved.  In my opinion it has to
> be Local.
There were people who believed you "had" to specify network
type in localControl.  I never understood why; SDP and Annex D
fully describe network type.  Other than that, I think we all
agree, it's local, not localControl.

Brian

---

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 4 Jan 2000 13:24:26 -0500

We're getting close.  Just a couple of points.

> Sent: Tuesday, January 04, 2000 10:11 AM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]; [email-masked]
        [[TomT]]  agreed points snipped

>       (3) What is the meaning of an empty descriptor when sent from the
> MGC to the MG?  when sent from the MG to the MGC?
>
>       [BR] First of all, there is a big difference between empty and not
> mentioned.  I think empty from MGC to MG is "I have no policy, tell me all
> you can do".  I think empty from MG to MGC is an error.
>
                [[TomT]]  I assume it's not just "tell me all you can do",
but also "reserve resources for what you tell me about".

        [[TomT]]  ...
>
>       (5) Do we accept the distinction between simultaneous resource
> commitments (be prepared to accept/apply any of these at any time) vs.
> mutually exclusive commitments (reserve resources to handle any one of
> these possibilities, but in the end we'll commit to just one)?  Do we
> accept that simultaneous commitments are described within a single media
> session description, while mutually exclusive commitments are described in
> separate session descriptions?
>
>       [BR] I'm confused.  I don't understand the distinction, and I don't
> understand the syntax differences.  To me, the overspecified local with no
> remote is "be prepared to accept/apply any of these resources, reserving
> whatever resources you might need to do so".  In the end, you ALWAYS
> commit to just one.
>
                [[TomT]]
                You may alternate, as in simultaneous use of G.723.1 and the
TONES payload.  Thus you commit to two encodings and corresponding payload
types rather than one.

                Here is the syntax as I see it:

                v=0
                i=G.711 alternative -- the preferred one
                s=1
                ...
                m=audio $ RTP/AVP 0
                v=0
                i=G.723.1 plus TONES encoding
                s=2
                ...
                m=audio $ RTP/AVP 4 96
                a=rtpmap:96 X-TONES

                To quote from RFC 2327 (SDP):

     When a list of payload formats is given, this implies that all of
     these formats may be used in the session, but the first of these
     formats is the default format for the session.

                Thus a single session description listing G.711, G.723.1,
and TONES on the same line doesn't have the same meaning as what I show
above.  I'm proposing that the above means that the MG must reserve
resources to support both session 1 and session 2 for the moment.  This part
is straightforward.  The next part is special interpretation: that if
multiple session descriptions are given for the same stream, only one will
ever be used, so, for instance, the MG can assign the same port for every
session description.  Can we agree on this interpretation?

>               The syntax problem is pretty much a "local" thing.  On the
> originating end,
>       you want to ask for capability.  On the terminating end, you want to
> ask the
>       Working this out a little more, the originating MGC, having no idea
> what the
>       terminating side wants, has only its local policy. It puts this in
> local in

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 4 Jan 2000 17:31:13 -0500

[[TomT]]  I assume it's not just "tell me all you can do", but also "reserve
resources for what you tell me about".

         [BR] Agreed

mutually exclusive commitments (reserve resources to handle any one of these

        [BR] I'm confused.  I don't understand the distinction, and I don't
understand the syntax differences.  To me, the overspecified local with no
remote is "be prepared to accept/apply any of these resources, reserving
whatever resources you might need to do so".  In the end, you ALWAYS commit
to just one.

        [[TomT]]
You may alternate, as in simultaneous use of G.723.1 and the TONES payload.
Thus you commit to two encodings and corresponding payload types rather than
one.

        v=0

        Thus a single session description listing G.711, G.723.1, and TONES
on the same line doesn't have the same meaning as what I show above.  I'm
proposing that the above means that the MG must reserve resources to support
both session 1 and session 2 for the moment.  This part is straightforward.
The next part is special interpretation: that if multiple session
descriptions are given for the same stream, only one will ever be used, so,
for instance, the MG can assign the same port for every session description.
Can we agree on this interpretation?

        [BR] I had not realized that SDP had this capability.  Given that, I
agree.

                -----Original Message-----
From:   Rosen, Brian [SMTP:[email-masked]]
Sent:   Tuesday, January 04, 2000 8:28 AM
To:     [email-masked]
Subject:        Re: Proposed Text For Media Specification

                I think buffering is going to be needed if you are
encrypting.
The real question is whether you always have to do this, or there
is some way to know if you might be.

                The syntax problem is pretty much a "local" thing.  On the
originating end,
you want to ask for capability.  On the terminating end, you want to ask the
MG to make a choice.  In both cases, it's local that this happens in.  The
other end gets the result (the return from the add) as its remote.

                The following is more detail than you need, but I thought
I'd
write down how I think it works in great detail for others
to decide if they agree, or have a different view:

Working this out a little more, the originating MGC, having no idea what the
terminating side wants, has only its local policy. It puts this in local in

                The originating MGC sends this to the terminating MGC.  The
terminating MG

                The terminating MG gets the choices and chooses one for
local and
Assuming success, the terminating MGC returns the choice to the originating

                As with the prior discussion, this means local has what you
send,
and remote has what you receive (which is what the other end sends).

                You see the syntax issue in local?  The originating MG sees
an

                Brian

---

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 5 Jan 2000 10:23:25 -0600

I think your first alternative looks reasonable.  If I may, I'll restate
what you've said with a little amplification, as follows:

"When the MG receives a non-empty Remote Descriptor containing multiple
session descriptions, it must choose which of these descriptions it will
support and indicate its choice in its response to the MGC.  It makes this
choice according to the following logic:

(1) If the MGC did not provide a Local Descriptor in the command and no
resources were reserved for media reception by a previous command, then the
MG assumes that the stream will be send-only.  It selects the first session
description in Remote that it supports.

(2) If the MGC did not provide a Local Descriptor in the command, but
reserved resources by setting Local in a previous command, then the MG
compares the reserved resources against Remote and chooses according to the
following principles:

(a) If possible, the MG establishes a symmetric media flow, with the same
encoding for both directions.

(b) If multiple choices for symmetric media flows are available, it chooses
the one most preferred by the MGC as previously set in Local.

(c) If symmetric encoding is not possible, it chooses the first session
description in Remote that it supports, and returns that along with the
complete list of session descriptions in Local for which it has reserved
resources.

(3) If the MGC provided an empty Local Descriptor in the command what
happens?  According to our previous correspondence, it's something like
this:  the MG chooses the first session description in Remote that it
supports, but returns in Local all of the possibilities for which it was
able to reserve resources, given the selection in Remote.

(4) If the MGC provided a non-empty Local Descriptor, then the MG applies
the principles listed in (2) to make a unique choice for both Local and
Remote.

> From: Michael Thomas [SMTP:[email-masked]]
> Sent: Tuesday, January 04, 2000 9:43 PM
> To:   Taylor, Tom-PT [CAR:B904:EXCH]
> Cc:   Michael Thomas; [email-masked]
>  > In your second case in step (4), why doesn't the MG converge on the
> single
>  > selection s3 for Local and Remote?  How does it know that it should
> leave
>  > Local unresolved?
>
> You're right. There are two choices:
>
> 1) If we want to modify my description that the
>    MG should at each Local descriptor in order
>    and for each descriptor it can accommodate,
>    it should then look into the choices in the
>    Remote descriptor. If it finds a matching
>    descriptor, it should select that SDP alone
>    for both Remote and Local, otherwise it
>    keeps checking the choices within Local
>    against Remote until a match if found, or
>    Local is exhausted. If Local is exhaused,
>    MGt should return the Local descriptors
>    it can accommodate, along with the most
>    prefereable descriptor in Remote.
>
>    The advantage here is that it preserves MGC
>    priorities while still converging on a symmetric
>    codec in a 3-way handshake.
>
> 2) We could leave it the way I have it, for
>    which it would choose s3. If so, would
>    you like me to contrive an example which
>    actually does the negotiation right?
>
>                 Mike
>
>
>  >
>  > > From:    Michael Thomas [SMTP:[email-masked]]
>  > > Sent:    Tuesday, January 04, 2000 11:57 AM
>  >    [[TomT]]  First case snipped.
>  >
>  > > For *asynchronous* negotiation we modify the flow
>  > > slightly:
>  > >
>  > >
>  > > 1) MGC->MGo: Add { Local { s1, s2, s3} Remote {}}
>  > >
>  > >    MGC sends initial add to the originator; remote
>  > >    unknown. Local choice are policy
>  > >
>  > > 2) MGo->MGC: Add = { Local { s1, s3} Remote {}}
>  > >
>  > >    MGo chooses s1 and s3; can't do s2 because of
>  > >    resources
>  > >
>  > > 3) MGC->MGt: Add { Local { s2, s3} Remote { s1, s3}}
>  > >
>  > >    MGC adds MGt, sets policy in local, sends
>  > >    choices in remote from MGo; note MGC sends
>  > >    policy of not using s1 (for whatever reason)
>  > >
>  > > 4) MGt->MGC: Add = { Local { s2, s3 } Remote {s1}}
>  > >
>  > >    MGt firstly notices that Remote has choices. It
>  > >    then SHOULD take the intersection of Local and
>  > >    Remote's choices and return the most preferable
>  > >    choice (ie, first in list). If there is not an
>  > >    intersection, MG MUST choose one in Remote and
>  > >    send back the choices in Local that it can
>  > >    accommodate (s2, s3).
>  > >
>  > > 5) MGC->MGo: Modify { Local { s1 } Remote { s2, s3 }}
>  > >
>  > >    MGC modifies MGo with the choices. Note Remote
>  > >    is not fully qualified. The MGC MUST at this
>  > >    point remember that it needs to do a 4 way
>  > >    handshake since it saw choices in remote going
>  > >    to MGo
>  > >
>  > > 6) MGo->MGC: Modify = { Local { s1 } Remote { s3}}
>  > >
>  > >    MGo acks the Modify, and chooses s3 because it
>  > >    still cannot do s2 in remote
>  > >
>  > > 7) MGC->MGt: Modify { Local { s3 } Remote { s1 }}
>  > >
>  > >    MGC transmits the final  choices to MGt
>  > >
>  > > 8) MGt->MGC: Modify = { Local { s3 } Remote { s1}}
>  > >
>  > >    MGt acks the modify and we're going.
>  > >
>  > >             Mike
>  > >
>  > > Rosen, Brian writes:
>  > >  > MG to make a choice.  In both cases, it's local that this happens
> in.
>  > > The
> terminating
>  > > MG
>  > >  > > Sent: Monday, January 03, 2000 6:21 PM
>  > >  > > To: Rosen, Brian
>  > >  > > Cc: [email-masked]
>  > >  > >    That's what I was afraid of. This implies that either
>  > >  > >    you load all of the proposed codecs (not just
>  > >  > >    account for their maximum MIPS and ram as you
>  > >  > >    implied), or you  better be able to load the
>  > >  > >    codec PDQ once you see the first media packet.
>  > >  > >
>  > >  > >    A worse problem is if you want to negotiate
>  > >  > >    cipher suites with payload encryption. There,
>  > >  > >    unless cipher suite negotiation is tied to the
>  > >  > >    type field somehow (it is not in packetcable,
>  > >  > >    as one data point), you have no clue how the
>  > >  > >    packet is encrypted, which effectively causes
>  > >  > >    front end clipping too.
>  > >  > >
>  > >  > >    Since a 4-way handshake is a pretty heinous
>  > >  > >    necessity, maybe the right thing to do would be
>  > >  > >    to buffer the packets in the playback buffer
>  > >  > >    and not process them until the last Modify
>  > >  > >    came in -- this gives the whole playback
>  > >  > >    delay for the arrival of the Modify before you
>  > >  > >    had to drop the packets on the head of the
>  > >  > >    queue.
>  > >  > >
>  > >  > >    Isn't this where Local and Remote come into
>  > >  > >    play? If I see several choices in Remote (eg
>  > >  > >    the other side's local), isn't that the trigger
>  > >  > >    for me to choose one? Or am I all screwed up here?
>  > >  > >
>  > >  > >            Mike
>  > >  > >  >
>  > >  > >  > Brian
>  > >  > >  >
>  > >  > >  > >  > I'm willing to follow this thought along a bit further.
> I
>  > >  > >  > > think the
>  > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
>  > <HTML>
>  > <HEAD>
>  > <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
>  > <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2448.0">
>  > </HEAD>
>  > <P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">In your second case in
> step (4), why doesn't the MG converge on the single selection s3 for Local
> and Remote?&nbsp; How does it know that it should leave Local
> unresolved?</FONT></P>
>  > <UL>
>  > <P><FONT SIZE=1 FACE="Arial">-----Original Message-----</FONT>
>  > <BR><B><FONT SIZE=1 FACE="Arial">From:&nbsp;&nbsp;</FONT></B> <FONT
> SIZE=1 FACE="Arial">Michael Thomas [SMTP:[email-masked]]</FONT>
>  > <BR><B><FONT SIZE=1 FACE="Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT
> SIZE=1 FACE="Arial">Tuesday, January 04, 2000 11:57 AM</FONT>
>  > <BR><B><I><FONT COLOR="#0000FF" SIZE=2
> FACE="Arial">[[TomT]]</FONT></I></B><I></I>&nbsp;<FONT COLOR="#0000FF"
> SIZE=2 FACE="Arial"> First case snipped.</FONT><B></B><B></B><B><FONT
> SIZE=1 FACE="Arial"></FONT></B>
>  > </P>
>  >
>  > <P><FONT SIZE=2 FACE="Arial">For *asynchronous* negotiation we modify
> the flow</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">slightly:</FONT>
>  > </P>
>  > <BR>
>  >
>  > <P><FONT SIZE=2 FACE="Arial">1) MGC-&gt;MGo: Add { Local { s1, s2, s3}
> Remote {}}</FONT>
>  > </P>
>  >
>  > <P><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; MGC sends initial add to the
> originator; remote</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; unknown. Local choice are
> policy</FONT>
>  > </P>
>  >
>  > <P><FONT SIZE=2 FACE="Arial">2) MGo-&gt;MGC: Add = { Local { s1, s3}
> Remote {}}</FONT>
>  > </P>
>  >
>  > <P><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; MGo chooses s1 and s3; can't
> do s2 because of</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; resources</FONT>
>  > </P>
>  >
>  > <P><FONT SIZE=2 FACE="Arial">3) MGC-&gt;MGt: Add { Local { s2, s3}
> Remote { s1, s3}}</FONT>
>  > </P>
>  >
>  > <P><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; MGC adds MGt, sets policy in
> local, sends</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; choices in remote from MGo;
> note MGC sends</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; policy of not using s1 (for
> whatever reason)</FONT>
>  > </P>
>  >
>  > <P><FONT SIZE=2 FACE="Arial">4) MGt-&gt;MGC: Add = { Local { s2, s3 }
> Remote {s1}}</FONT>
>  > </P>
>  >
>  > <P><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; MGt firstly notices that
> Remote has choices. It</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; then SHOULD take the
> intersection of Local and</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; Remote's choices and return
> the most preferable</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; choice (ie, first in list).
> If there is not an</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; intersection, MG MUST choose
> one in Remote and</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; send back the choices in
> Local that it can</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; accommodate (s2, s3).</FONT>
>  > </P>
>  >
>  > <P><FONT SIZE=2 FACE="Arial">5) MGC-&gt;MGo: Modify { Local { s1 }
> Remote { s2, s3 }}</FONT>
>  > </P>
>  >
>  > <P><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; MGC modifies MGo with the
> choices. Note Remote</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; is not fully qualified. The
> MGC MUST at this</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; point remember that it needs
> to do a 4 way</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; handshake since it saw
> choices in remote going</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; to MGo</FONT>
>  > </P>
>  >
>  > <P><FONT SIZE=2 FACE="Arial">6) MGo-&gt;MGC: Modify = { Local { s1 }
> Remote { s3}}</FONT>
>  > </P>
>  >
>  > <P><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; MGo acks the Modify, and
> chooses s3 because it</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; still cannot do s2 in
> remote</FONT>
>  > </P>
>  >
>  > <P><FONT SIZE=2 FACE="Arial">7) MGC-&gt;MGt: Modify { Local { s3 }
> Remote { s1 }}</FONT>
>  > </P>
>  >
>  > <P><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; MGC transmits the final&nbsp;
> choices to MGt</FONT>
>  > </P>
>  >
>  > <P><FONT SIZE=2 FACE="Arial">8) MGt-&gt;MGC: Modify = { Local { s3 }
> Remote { s1}}</FONT>
>  > </P>
>  >
>  > <P><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; MGt acks the modify and we're
> going.</FONT>
>  > </P>
>  >
>  > <P><FONT SIZE=2
> FACE="Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
> nbsp; Mike</FONT>
>  > </P>
>  >
>  > <P><FONT SIZE=2 FACE="Arial">Rosen, Brian writes:</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; I think buffering is going to
> be needed if you are encrypting.</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; The real question is whether
> you always have to do this, or there</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; is some way to know if you
> might be.</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt;</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; The syntax problem is pretty
> much a &quot;local&quot; thing.&nbsp; On the originating end,</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; you want to ask for
> capability.&nbsp; On the terminating end, you want to ask the</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; MG to make a choice.&nbsp; In
> both cases, it's local that this happens in.&nbsp; The</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; other end gets the result (the
> return from the add) as its remote.</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt;</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; The following is more detail
> than you need, but I thought I'd</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; write down how I think it
> works in great detail for others</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; to decide if they agree, or
> have a different view:</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt;</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; More specifically, the
> originating end gets the terminating</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; end's local as its remote,
> while the terminating end gets a</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; negotiated version of the
> originating end's local as its remote).</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; Working this out a little
> more, the originating MGC, having no idea what the</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; terminating side wants, has
> only its local policy. It puts this in local in</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; the first Add.&nbsp; The
> originating MG filters this (takes out what it can't</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; do), reserving worst case
> resources, and</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; returns this filtered version
> of local in the response to the Add.</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; There is no remote at all in
> this Add, because the originating MGC</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; doesn't know any part of what
> goes in remote.</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt;</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; The originating MGC sends this
> to the terminating MGC.&nbsp; The terminating MG</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; filters the received proposal
> with its policy,</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; and sends it in remote.&nbsp;
> If it will allow asymmetric coding (unusual)</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; it could just send its policy
> in local, but in most cases, it will</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; just present the same coding
> options it got from the originating</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; end, filtered by it's policy
> (which could be reordering, as well</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; as removing options) in
> local.</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt;</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; The terminating MG gets the
> choices and chooses one for local and</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; remote (usually the same,
> could be different) if it can and returns</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; the single chosen value in the
> reply to its add.&nbsp; If it cannot,</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; it means none of the offered
> choices are acceptable.&nbsp; In that case</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; it must return an error.&nbsp;
> The response to this error might be</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; to attempt the Add again with
> just the terminating end's policy,</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; which would be returned, and
> then the terminating end can propose</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; those choices in a full (non
> fast start) negotiation.</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; Assuming success, the
> terminating MGC returns the choice to the originating</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; MGC, which modifies the
> termination, both in local and</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; remote.</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt;</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; As with the prior discussion,
> this means local has what you send,</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; and remote has what you
> receive (which is what the other end sends).</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt;</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; You see the syntax issue in
> local?&nbsp; The originating MG sees an</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; Add with an overspecified
> local, but returns an overspecified local.</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; The terminating MG sees an Add
> with an overspecified local but</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; returns a fully specified
> local.&nbsp; The originating MG doesn't get</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; a remote with the add.&nbsp;
> The terminating MG sees an overspecified remote</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; which it returns fully
> specified.</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt;</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; Brian</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt;</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt; -----Original
> Message-----</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt; From: Michael Thomas
> [<U></U></FONT><U><FONT COLOR="#0000FF" SIZE=2 FACE="Arial"><A
> HREF="mailto:[email-masked]">mailto:[email-masked]</A></FONT></U><FONT
> SIZE=2 FACE="Arial">]</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt; Sent: Monday, January 03,
> 2000 6:21 PM</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt; To: Rosen, Brian</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt; Cc:
> [email-masked]</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt; Subject: Re: Proposed
> Text For Media Specification</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt; Rosen, Brian
> writes:</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; If true, it
> means if you see media before the modify, then you</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; start
> decoding, and if the modify says something different than</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; you implied
> from the header, it's an error.&nbsp; It isn't necessary to</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; wait until you
> get the modify before you can process the media.</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; I suppose that
> since there is the possibility of asymmetric coding,</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; you can't send
> any media until you have the modify.</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp;&nbsp;&nbsp; That's
> what I was afraid of. This implies that either</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp;&nbsp;&nbsp; you
> load all of the proposed codecs (not just</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp;&nbsp;&nbsp; account
> for their maximum MIPS and ram as you</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp;&nbsp;&nbsp;
> implied), or you&nbsp; better be able to load the</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp;&nbsp;&nbsp; codec
> PDQ once you see the first media packet.</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp;&nbsp;&nbsp; A worse
> problem is if you want to negotiate</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp;&nbsp;&nbsp; cipher
> suites with payload encryption. There,</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp;&nbsp;&nbsp; unless
> cipher suite negotiation is tied to the</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp;&nbsp;&nbsp; type
> field somehow (it is not in packetcable,</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp;&nbsp;&nbsp; as one
> data point), you have no clue how the</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp;&nbsp;&nbsp; packet
> is encrypted, which effectively causes</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp;&nbsp;&nbsp; front
> end clipping too.</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp;&nbsp;&nbsp; Since a
> 4-way handshake is a pretty heinous</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp;&nbsp;&nbsp;
> necessity, maybe the right thing to do would be</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp;&nbsp;&nbsp; to
> buffer the packets in the playback buffer</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp;&nbsp;&nbsp; and not
> process them until the last Modify</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp;&nbsp;&nbsp; came in
> -- this gives the whole playback</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp;&nbsp;&nbsp; delay
> for the arrival of the Modify before you</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp;&nbsp;&nbsp; had to
> drop the packets on the head of the</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp;&nbsp;&nbsp;
> queue.</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; HOWEVER, this
> means we need syntax to differentiate between an</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; add with
> policy, respond with capability, and add with policy,</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; choose one and
> respond with your choice.</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp;&nbsp;&nbsp; Isn't
> this where Local and Remote come into</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp;&nbsp;&nbsp; play?
> If I see several choices in Remote (eg</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp;&nbsp;&nbsp; the
> other side's local), isn't that the trigger</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp;&nbsp;&nbsp; for me
> to choose one? Or am I all screwed up here?</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt;
> &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
> Mike</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt;</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; Brian</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt;</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; &gt;
> -----Original Message-----</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; &gt; From:
> Michael Thomas [</FONT><U><FONT COLOR="#0000FF" SIZE=2 FACE="Arial"><A
> HREF="mailto:[email-masked]">mailto:[email-masked]</A></FONT></U><FONT
> SIZE=2 FACE="Arial">]</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; &gt; Sent:
> Monday, January 03, 2000 1:47 PM</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; &gt; To:
> [email-masked]</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; &gt; Subject:
> Re: Proposed Text For Media Specification</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; &gt;</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; &gt;</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; &gt; Tom-PT
> Taylor writes:</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; &gt;&nbsp;
> &gt; I'm willing to follow this thought along a bit further.&nbsp;
> I</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; &gt; think
> the</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; &gt;&nbsp;
> &gt; concrete difference between the viewpoint I've</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt; documented and the</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; &gt;&nbsp;
> &gt; &quot;policy-capability&quot; viewpoint is this: if the MGC
> sends</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; &gt; down a
> number of</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; &gt;&nbsp;
> &gt; alternative session descriptions, in my case the MG picks</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; &gt; one,
> while in</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; &gt;&nbsp;
> &gt; Brian's case the MG replies with all the session</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; &gt;
> descriptions it can</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; &gt;&nbsp;
> &gt; currently support.&nbsp; I am willing to accept the latter</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; &gt;
> proposition if we can</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; &gt;&nbsp;
> &gt; all agree on it.&nbsp; From there, I will go forward with</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; &gt; Chip's
> distinction</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; &gt;&nbsp;
> &gt; between the roles of Local and Remote, and I think we'll</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; &gt; have a
> good</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; &gt;&nbsp;
> &gt; sensible result.</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; &gt;</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt;
> &gt;&nbsp;&nbsp;&nbsp; Aside from the issue of not wanting to
> recreate</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt;
> &gt;&nbsp;&nbsp;&nbsp; syntax when you could use SDP to do the
> same,</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt;
> &gt;&nbsp;&nbsp;&nbsp; there are three constraints which we must
> adhere</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt;
> &gt;&nbsp;&nbsp;&nbsp; to:</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; &gt;</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt;
> &gt;&nbsp;&nbsp;&nbsp; 1) Negotiation must happen with a three way
> handshake</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt;
> &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; between the MGC and the two MG's:
> eg</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;
> Add(o)/Add(t)/Modify(o)</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt;
> &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I think that Tom's original
> proposal does not meet this</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt;
> &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; requirement, though Brian's
> does.</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; &gt;</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt;
> &gt;&nbsp;&nbsp;&nbsp; 2) MG's which offer the set of codec alternatives
> in</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt;
> &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Brian's proposal MUST NOT be
> expected to have those</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt;
> &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; coders actually loaded and
> prepared to process media</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt;
> &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; packets. The MG will only prepare
> itself for receipt</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt;
> &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of packets when it sees a single
> choice.</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; &gt;</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt;
> &gt;&nbsp;&nbsp;&nbsp; 3) The entire process MUST NOT lead to front end
> clipping.</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt;
> &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I'm not sure how you do this
> given the other constraints</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt;
> &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; other than making it into a 4 way
> handshake. Maybe somebody</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt;
> &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; more clever than me can solve
> that problem.</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; &gt;</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; &gt;</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt;
> &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs
> p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mike</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt; &gt;</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt;</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;&nbsp; &gt;</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; &gt;</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt;</FONT>
>  > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt;</FONT>
>  > </P>
>  > </UL>
>  > </BODY>
>  > </HTML>

---

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 10 Jan 2000 20:53:55 -0500

I prefer LocalControl because that gives you per-stream control.  That may
be useful to allow previously-established streams to remain undisturbed if
H.245 is used to negotiate new ones.

> From: Christian Groves [SMTP:[email-masked]]
> Sent: Tuesday, January 11, 2000 4:15 AM
> G'Day Tom,
> I support the introduction of parameters for 'choose' or 'reserveALL' to
> support Fast Connect.
>
> Would another alternative to Local Control to be to add it to the
> command syntax as 'choose' or 'reserve' would be related to commands?
> ie.
> ADD(Ctxt1),T1,[reserve+choose],Local[P1=v1,p2=v2],Remote[p3=v3,p4=v4]
>
> Cheers, Christian
>
> Tom-PT Taylor wrote:
> >
> > Unfortunately this doesn't seem to be quite the last word.  From
> > H.323v2 section 8.1.7 "Fast Connect Procedure", here is how fast
> > connect works.
> >
> > <quote>
> >
> > "The calling endpoint initiates the Fast Connect procedure by sending
> > a SETUP message containing the
> > fastStart element to the called endpoint. The fastStart element
> > consists of a sequence of
> > OpenLogicalChannel structures describing media channels which the
> > calling endpoint proposes to send
> > and receive, including all of the parameters necessary to immediately
> > open and begin transferring
> > media on the channels. Details of the content and usage of the
> > fastStart element are discussed below.
> > ...
> > "The called endpoint may begin transmitting media (according to the
> > channels opened) immediately
> > after sending a Q.931 message containing fastStart. The calling
> > endpoint must therefore be prepared
> > to receive media on any of the receive channels it proposed in the
> > SETUP message, since it is possible
> > for the media to be received prior to the Q.931 message indicating
> > precisely which channels will be
> > used. Once a Q.931 message containing fastStart is received by the
> > calling endpoint, the calling
> > endpoint may discontinue attempting to receive media on the channels
> > for which proposals were not
> > accepted by the called endpoint. Note that national requirements may
> > prohibit called endpoints from
> > transmitting media, or limit the nature of the content of the media
> > stream, prior to transmission of a
> > CONNECT message; it is the responsibility of the endpoint to comply
> > with applicable requirements. If
> > the calling endpoint sets the mediaWaitForConnect element to TRUE in
> > the SETUP message, then the
> > called endpoint shall not send any media until after the CONNECT
> > message is sent."
> >
> > </quote>
> >
> > Note particularly that the originating end has to reserve resources
> > for both the send and receive directions of flow.  This issue here is
> > that the originating end may want to reserve alternatives, leaving the
> > far end to choose from amongst them.  This implies a non-empty Remote
> > Descriptor, which according to the rules stated below would cause the
> > originating MG to select a single alternative rather than reserve
> > resources for everything proposed.
> >
> > The answer probably lies in adding a parameter to LocalControl, with
> > the two values "choose" or "reserveAll".  If "choose" is specified the
> > rules below are applied.  Otherwise the MG reserves resources as
> > specified in Local and Remote according to the listed order of
> > preference, and is prepared to receive any flow listed in Local
> > immediately upon responding to the MGC.
> >
> > One more issue here:  what to fill in for the far-end address in
> > Remote, pending a response from the far end?  I proposed using dashes
> > earlier, but how about following a convention used in SIP and
> > supplying an address consisting of all zeroes?
> >
> >      From:   Taylor, Tom-PT [CAR:B904:EXCH]
> >      Sent:   Wednesday, January 05, 2000 11:23 AM
> >      I think your first alternative looks reasonable.  If I may, I'll
> >      restate what you've said with a little amplification, as follows:
> >
> >      "When the MG receives a non-empty Remote Descriptor containing
> >      multiple session descriptions, it must choose which of these
> >      descriptions it will support and indicate its choice in its
> >      response to the MGC.  It makes this choice according to the
> >      following logic:
> >
> >      (1) If the MGC did not provide a Local Descriptor in the command
> >      and no resources were reserved for media reception by a previous
> >      command, then the MG assumes that the stream will be send-only.
> >      It selects the first session description in Remote that it
> >      supports.
> >
> >      (2) If the MGC did not provide a Local Descriptor in the command,
> >      but reserved resources by setting Local in a previous command,
> >      then the MG compares the reserved resources against Remote and
> >      chooses according to the following principles:
> >
> >      (a) If possible, the MG establishes a symmetric media flow, with
> >      the same encoding for both directions.
> >
> >      (b) If multiple choices for symmetric media flows are available,
> >      it chooses the one most preferred by the MGC as previously set in
> >      Local.
> >
> >      (c) If symmetric encoding is not possible, it chooses the first
> >      session description in Remote that it supports, and returns that
> >      along with the complete list of session descriptions in Local for
> >      which it has reserved resources.
> >
> >      (3) If the MGC provided an empty Local Descriptor in the command
> >      what happens?  According to our previous correspondence, it's
> >      something like this:  the MG chooses the first session
> >      description in Remote that it supports, but returns in Local all
> >      of the possibilities for which it was able to reserve resources,
> >      given the selection in Remote.
> >
> >      (4) If the MGC provided a non-empty Local Descriptor, then the MG
> >      applies the principles listed in (2) to make a unique choice for
> >      both Local and Remote.
> >
> >       > In your second case in step (4), why doesn't the MG converge
> >      on the single
> >       > selection s3 for Local and Remote?  How does it know that it
> >      should leave
> >       > Local unresolved?
> >
> >       > >  > MG to make a choice.  In both cases, it's local that this
> >      happens in.
> >       > > The
> >       > >  > the first Add.  The originating MG filters this (takes
> >      out what it
> >       > > can't
> >       > >  > The originating MGC sends this to the terminating MGC.
> >      The terminating
> >       > > MG
> >       > >  > > From: Michael Thomas [ <mailto:[email-masked]>]
> >       > >  > >  > I suppose that since there is the possibility of
> >      asymmetric
> >       > > coding,
> >       > >  > >  > > From: Michael Thomas [ <mailto:[email-masked]>]
> >       > >  > >  > >  > I'm willing to follow this thought along a bit
> >      further.  I
> >       > >  > >  > > think the
> >       > >  > >  > >  > "policy-capability" viewpoint is this: if the
> >      MGC sends
> >       > >  > >  > > down a number of
> >       > >  > >  > >  > Brian's case the MG replies with all the
> >      session
> >       > >  > >  > > descriptions it 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.
> >       > >  > >  > >
> >       > >  > >  > >       other than making it into a 4 way handshake.
> >      Maybe
> >       > > somebody
> >       > <P><FONT COLOR="#0000FF" SIZE=2 FACE="Arial">In your second
> >      case in step (4), why doesn't the MG converge on the single
> >      selection s3 for Local and Remote?&nbsp; How does it know that it
> >      should leave Local unresolved?</FONT></P>
> >
> >               > <UL>
> >       > <BR><B><FONT SIZE=1 FACE="Arial">From:&nbsp;&nbsp;</FONT></B>
> >      <FONT SIZE=1 FACE="Arial">Michael Thomas
> >      [SMTP:[email-masked]]</FONT>
> >
> >               > <BR><B><FONT SIZE=1
> >      FACE="Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT SIZE=1
> >      FACE="Arial">Tuesday, January 04, 2000 11:57 AM</FONT>
> >
> >      FACE="Arial">[[TomT]]</FONT></I></B><I></I>&nbsp;<FONT
> >      COLOR="#0000FF" SIZE=2 FACE="Arial"> First case
> >      snipped.</FONT><B></B><B></B><B><FONT SIZE=1
> >      FACE="Arial"></FONT></B>
> >
> >               > </P>
> >       >
> >       > <P><FONT SIZE=2 FACE="Arial">For *asynchronous* negotiation we
> >      modify the flow</FONT>
> >       > <P><FONT SIZE=2 FACE="Arial">1) MGC-&gt;MGo: Add { Local { s1,
> >      s2, s3} Remote {}}</FONT>
> >       > </P>
> >       >
> >       > <P><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; MGC sends initial
> >      add to the originator; remote</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; unknown. Local
> >      choice are policy</FONT>
> >       > </P>
> >       >
> >       > <P><FONT SIZE=2 FACE="Arial">2) MGo-&gt;MGC: Add = { Local {
> >      s1, s3} Remote {}}</FONT>
> >       > </P>
> >       >
> >       > <P><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; MGo chooses s1 and
> >      s3; can't do s2 because of</FONT>
> >       > <P><FONT SIZE=2 FACE="Arial">3) MGC-&gt;MGt: Add { Local { s2,
> >      s3} Remote { s1, s3}}</FONT>
> >       > </P>
> >       >
> >       > <P><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; MGC adds MGt, sets
> >      policy in local, sends</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; choices in remote
> >      from MGo; note MGC sends</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; policy of not using
> >      s1 (for whatever reason)</FONT>
> >       > </P>
> >       >
> >       > <P><FONT SIZE=2 FACE="Arial">4) MGt-&gt;MGC: Add = { Local {
> >      s2, s3 } Remote {s1}}</FONT>
> >       > </P>
> >       >
> >       > <P><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; MGt firstly notices
> >      that Remote has choices. It</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; then SHOULD take
> >      the intersection of Local and</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; Remote's choices
> >      and return the most preferable</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; choice (ie, first
> >      in list). If there is not an</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; intersection, MG
> >      MUST choose one in Remote and</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; send back the
> >      choices in Local that it can</FONT>
> >       > <P><FONT SIZE=2 FACE="Arial">5) MGC-&gt;MGo: Modify { Local {
> >      s1 } Remote { s2, s3 }}</FONT>
> >       > </P>
> >       >
> >       > <P><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; MGC modifies MGo
> >      with the choices. Note Remote</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; is not fully
> >      qualified. The MGC MUST at this</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; point remember that
> >      it needs to do a 4 way</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; handshake since it
> >      saw choices in remote going</FONT>
> >       > <P><FONT SIZE=2 FACE="Arial">6) MGo-&gt;MGC: Modify = { Local
> >      { s1 } Remote { s3}}</FONT>
> >       > </P>
> >       >
> >       > <P><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; MGo acks the Modify,
> >      and chooses s3 because it</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; still cannot do s2
> >      in remote</FONT>
> >       > </P>
> >       >
> >       > <P><FONT SIZE=2 FACE="Arial">7) MGC-&gt;MGt: Modify { Local {
> >      s3 } Remote { s1 }}</FONT>
> >       > </P>
> >       >
> >       > <P><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; MGC transmits the
> >      final&nbsp; choices to MGt</FONT>
> >       > </P>
> >       >
> >       > <P><FONT SIZE=2 FACE="Arial">8) MGt-&gt;MGC: Modify = { Local
> >      { s3 } Remote { s1}}</FONT>
> >       > </P>
> >       >
> >       > <P><FONT SIZE=2 FACE="Arial">&nbsp;&nbsp; MGt acks the modify
> >      and we're going.</FONT>
> >       > </P>
> >       >
> >       > <P><FONT SIZE=2
> >
> nbsp;
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; I think buffering is
> >      going to be needed if you are encrypting.</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; The real question is
> >      whether you always have to do this, or there</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; is some way to know
> >      if you might be.</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; The syntax problem is
> >      pretty much a &quot;local&quot; thing.&nbsp; On the originating
> >      end,</FONT>
> >
> >               > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; you want to
> >      ask for capability.&nbsp; On the terminating end, you want to ask
> >      the</FONT>
> >
> >               > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; MG to make a
> >      choice.&nbsp; In both cases, it's local that this happens
> >      in.&nbsp; The</FONT>
> >
> >               > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; other end
> >      gets the result (the return from the add) as its remote.</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; The following is more
> >      detail than you need, but I thought I'd</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; write down how I
> >      think it works in great detail for others</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; to decide if they
> >      agree, or have a different view:</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; More specifically,
> >      the originating end gets the terminating</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; end's local as its
> >      remote, while the terminating end gets a</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; negotiated version of
> >      the originating end's local as its remote).</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; Working this out a
> >      little more, the originating MGC, having no idea what the</FONT>
> >
> >               > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; terminating
> >      side wants, has only its local policy. It puts this in local
> >      in</FONT>
> >
> >               > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; the first
> >      Add.&nbsp; The originating MG filters this (takes out what it
> >      can't</FONT>
> >
> >               > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; do),
> >      reserving worst case resources, and</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; returns this filtered
> >      version of local in the response to the Add.</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; There is no remote at
> >      all in this Add, because the originating MGC</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; doesn't know any part
> >      of what goes in remote.</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; The originating MGC
> >      sends this to the terminating MGC.&nbsp; The terminating
> >      MG</FONT>
> >
> >               > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; filters the
> >      received proposal with its policy,</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; and sends it in
> >      remote.&nbsp; If it will allow asymmetric coding (unusual)</FONT>
> >
> >               > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; it could just
> >      send its policy in local, but in most cases, it will</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; just present the same
> >      coding options it got from the originating</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; end, filtered by it's
> >      policy (which could be reordering, as well</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; as removing options)
> >      in local.</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; The terminating MG
> >      gets the choices and chooses one for local and</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; remote (usually the
> >      same, could be different) if it can and returns</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; the single chosen
> >      value in the reply to its add.&nbsp; If it cannot,</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; it means none of the
> >      offered choices are acceptable.&nbsp; In that case</FONT>
> >
> >               > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; it must
> >      return an error.&nbsp; The response to this error might be</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; to attempt the Add
> >      again with just the terminating end's policy,</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; which would be
> >      returned, and then the terminating end can propose</FONT>
> >       > <BR><FONT SIZE=2 FACE="Arial">&nbsp;&gt; those choices in a
> >      full (non fast start) negotiation.</FONT>

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 11 Jan 2000 08:41:06 -0500

Reserve All is misleading.  I don't think that it means anything
different from what was discussed some time ago, which is
that when the MG proposes a list of potential choices, it must
be prepared to accept media on any ONE of them, not ALL of them.

Suppose it took 1 units of compute power to encode/decode G.711,
5 units to process G.723 and 3 to process G.729a.  If the
originating MG proposes G.711, G.723, G.729a, it must reserve
5 units, not 9 units!

I still think we are confused about the difference between
the MG responding with multiple choices, and the MG being given
multiple choices.

At the originating MG if you are given multiple choices,
its policy from MGC to MG.  You can respond with multiple choices, which is
your proposal, and you must RESERVE the worst
case resources.  At the Terminating MG, if you are given
multiple choices, you must CHOOSE, and you always commit resources for the
one session description, if that was the
only thing offered, or among the choices, if more than one
was offered.

So we need some syntax, and the distinction probably ought to be
RESERVE and CHOOSE.  It's annoying to have to do it in LocalControl because
that is the only thing you need LocalControl for, so we have an entire
descriptor with one parameter, always followed by another descriptor.  It's
tempting to me to get the
syntax into the local/remote descriptor.  Easy in binary,
but some SDP in text.  Maybe just another keyword.

Brian

> From: Christian Groves [mailto:[email-masked]]
> >       > >  > The real question is whether you always have
> to do this,
> >      or there
> >       > >  > you want to ask for capability.  On the
> terminating end,
> >      you want to
> >       > > ask the
> >       > >  > end's local as its remote, while the
> terminating end gets
> >      a
> >       > >  > negotiated version of the originating end's
> local as its
> >      remote).
> >       > >  > returns this filtered version of local in the
> response to
> >      the Add.
> >       > >  > end, filtered by it's policy (which could be
> reordering,
> >      as well
> >       > >  > it means none of the offered choices are
> acceptable.  In
> >      that case
> >       > >  > to attempt the Add again with just the
> terminating end's
> >      policy,
> >       > >  > which would be returned, and then the
> terminating end can
> >      propose
> >       > >  > Assuming success, the terminating MGC returns
> the choice
> >      to the
> >       > > originating
> >       > >  > and remote has what you receive (which is what
> the other
> >      end sends).
> >       > >  >
> >       > >  > >  > wait until you get the modify before you
> can process
> >      the media.
> >       > >  > >  > HOWEVER, this means we need syntax to
> differentiate
> >      between an
> >       > >  > >  > >  > concrete difference between the
> viewpoint I've
> >       > >  > > documented and the
> >       > >  > >  > >  > currently support.  I am willing to
> accept the
> >      latter
> >       > >  > >  > > proposition if we can
> >       > >  > >  > >       packets. The MG will only prepare
> itself for
> >      receipt
> >       > >  > >  > >       I'm not sure how you do this
> given the other
> >      constraints
> FACE="Arial">From:&nbsp;&nbsp;</FONT></B>
> FACE="Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
> nbsp;&nbsp;&nbsp;
> >      Mike</FONT>
> >       > </P>
> >       >

---

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 11 Jan 2000 08:14:57 -0600

I don't care what you call it -- the intent is "reserve for all", whatever
that means for the given MG implementation.  Your example might be too
simple -- remember the point that code for each codec may have to be loaded,
so there could be an additive memory constraint.

You need LocalControl for Mode for sure, so you can't just eliminate it.  I
expect we will find other uses for it too.

> Sent: Tuesday, January 11, 2000 8:41 AM
> To:   'Christian Groves'; Taylor, Tom-PT [CAR:B904:EXCH];
> [email-masked]