Subject: Re: Proposed Text For Media Specification

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

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 08:57:15 -0800

Detail at this point is a Good Thing. I had always
thought that one of the motivations for Remote was
to enable asynchronous negotiation; remember that
MGCP only passes one SDP back and forth.

Here's a scenario, however, that I think satisfies
all of the conditions though:

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 { s1, s2, s3} Remote { s1, s3}}

   MGC adds MGt, sets policy in local, sends
   choices in remote from MGo

4) 1) MGt->MGC: Add = { Local { s1 } 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

5) MGC->MGo: Modify { Local { s1 } Remote { s1 }}

   MGC modifies MGo with the choices, which are
   fully qualified at this point.

6) 1) MGo->MGC: Modify = { Local { s1 } Remote { s1}}

   MGo acks the Modify

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