Subject: Re: Proposed Text For Media Specification

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

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

> -----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: Mon, 3 Jan 2000 15:21:25 -0800

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

 > 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