Subject: Re: Proposed Text For Media Specification

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 10 Jan 2000 15:42:52 -0500

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?

> -----Original Message-----
> From: Taylor, Tom-PT [CAR:B904:EXCH]
> Sent: Wednesday, January 05, 2000 11:23 AM
> To:   [email-masked]
> Subject:      Re: Proposed Text For Media Specification
>
> 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.
>
>       -----Original Message-----
> 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]
> Subject:        RE: Proposed Text For Media Specification
>
>       Tom-PT Taylor writes:
>  > 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
>
>
>  >
>  > > -----Original Message-----
>  > > 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:
>  > >  > 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
>  > >  >
>  > >  > > -----Original Message-----
>  > >  > > From: Michael Thomas [ <mailto:[email-masked]>]
>  > >  > > Sent: Monday, January 03, 2000 6:21 PM
>  > >  > > To: Rosen, Brian
>  > >  > > Cc: [email-masked]
>  > >  > > Subject: Re: Proposed Text For Media Specification
>  > >  > >
>  > >  > >
>  > >  > > Rosen, Brian writes:
>  > >  > >  > 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.
>  > >  > >
>  > >  > >    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.
>  > >  > >
>  > >  > >  > 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.
>  > >  > >
>  > >  > >    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
>  > >  > >  >
>  > >  > >  > > -----Original Message-----
>  > >  > >  > > From: Michael Thomas [ <mailto:[email-masked]>]
>  > >  > >  > > Sent: Monday, January 03, 2000 1:47 PM
>  > >  > >  > > To: [email-masked]
>  > >  > >  > > Subject: Re: Proposed Text For Media Specification
>  > >  > >  > >
>  > >  > >  > >
>  > >  > >  > > Tom-PT Taylor writes:
>  > >  > >  > >  > 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.
>  > >  > >  > >
>  > >  > >  > >    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
>  > >  > >  > >
>  > >  > >  >
>  > >  > >  >
>  > >  > >
>  > >  >
>  > >  >
>  > <!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">
>
>  > <TITLE>RE: Proposed Text For Media Specification</TITLE>
>  > </HEAD>
>  > <BODY>
>  >
>  > <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: Christian Groves <[email-masked]>
Date: Tue, 11 Jan 2000 10:15:22 +0100

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
> 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?
>
>      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?
>
>       > >  > 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
>       > >  > Working this out a little more, the originating MGC,
>      having no idea
>       > > what the
>       > >  > The originating MGC sends this to the terminating MGC.
>      The terminating
>       > > MG
>       > >  > and sends it in remote.  If it will allow asymmetric
>      coding (unusual)
>       > >  > remote (usually the same, could be different) if it can
>      and returns
>       > >  > and remote has what you receive (which is what the other
>      end sends).
>       > >  >
>       > >  > Add with an overspecified local, but returns an
>      overspecified local.
>       > >  > a remote with the add.  The terminating MG sees an
>      overspecified remote
>       > >  > >  > 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.
>       > >  > >  > HOWEVER, this means we need syntax to differentiate
>      between an
>       > >  > >  > add with policy, respond with capability, and add
>      with policy,
>       > >  > >  > >  > I'm willing to follow this thought along a bit
>      further.  I
>       > >  > >  > > think the
>       > >  > >  > >  > alternative session descriptions, in my case
>      the MG picks
>       > >  > >  > > one, while in
>       > >  > >  > >       I think that Tom's original proposal does
>      not meet this
>       > >  > >  > >    3) The entire process MUST NOT lead to front
>      end clipping.
>       > <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
>      FACE="Arial">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
>      Mike</FONT>
>       > </P>
>       >
>       > <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>
>
>      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>