Subject: Re: Proposed Text For Media Specification

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 4 Jan 2000 11:29:25 -0600

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?

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

---

From: Michael Thomas <[email-masked]>
Date: Tue, 4 Jan 2000 18:42:41 -0800

> selection s3 for Local and Remote?  How does it know that it should leave

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

 > <!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;&nbsp;&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>