Subject: Re: Proposed Text For Media Specification

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

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

[BR] Hmmmm, not a really wonderful way to differentiate, but it works and I
have no better idea

Now some syntactic nits:

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

[BR] I think the MG has to return a complete SDP description, whatever the
MGC said, so I would say yes.  I think this also improves interoperability,
as an MGC doesn't have to know all about various parameters.  Remember the
discussion of negotiation where the MGCs weren't aware of what they were
negotiating, but were able to decide anyway?

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

[BR] I agree, complete replacement

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

[BR] First of all, there is a big difference between empty and not
mentioned.  I think empty from MGC to MG is "I have no policy, tell me all
you can do".  I think empty from MG to MGC is an error.

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

[BR] A simple modify could omit local/remote with impunity.  An Add on the
originating side without a local should be legal, but you might get an error
when you modify to something real if the MG can't do it.  Similarly, it
ought to be okay on the terminating side.  I think if you specify a local,
and not a remote, you get the behavior we were discussing.  Remote without
local strikes me as an error.

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

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

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

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

        The syntax problem is pretty much a "local" thing.  On the
originating end,
you want to ask for capability.  On the terminating end, you want to ask the

MG to make a choice.  In both cases, it's local that this happens in.  The
other end gets the result (the return from the add) as its remote.

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

        More specifically, the originating end gets the terminating
end's local as its remote, while the terminating end gets a
negotiated version of the originating end's local as its remote).
Working this out a little more, the originating MGC, having no idea what the

terminating side wants, has only its local policy. It puts this in local in
the first Add.  The originating MG filters this (takes out what it can't
do), reserving worst case resources, and
returns this filtered version of local in the response to the Add.
There is no remote at all in this Add, because the originating MGC
doesn't know any part of what goes in remote.

        The originating MGC sends this to the terminating MGC.  The
terminating MG
filters the received proposal with its policy,
and sends it in remote.  If it will allow asymmetric coding (unusual)
it could just send its policy in local, but in most cases, it will
just present the same coding options it got from the originating
end, filtered by it's policy (which could be reordering, as well
as removing options) in local.

        The terminating MG gets the choices and chooses one for local and
remote (usually the same, could be different) if it can and returns
the single chosen value in the reply to its add.  If it cannot,
it means none of the offered choices are acceptable.  In that case
it must return an error.  The response to this error might be
to attempt the Add again with just the terminating end's policy,
which would be returned, and then the terminating end can propose
those choices in a full (non fast start) negotiation.
Assuming success, the terminating MGC returns the choice to the originating
MGC, which modifies the termination, both in local and
remote.

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

        You see the syntax issue in local?  The originating MG sees an
Add with an overspecified local, but returns an overspecified local.
The terminating MG sees an Add with an overspecified local but
returns a fully specified local.  The originating MG doesn't get
a remote with the add.  The terminating MG sees an overspecified remote
which it returns fully specified.

        Brian

---

From: John Segers <[email-masked]>
Date: Tue, 4 Jan 2000 17:00:09 +0100

This is going in the right direction.  I've got a couple of comments and
a question.

(3) (for clarification)  If a MGC supplies one fully specified (local)
descriptor, the MG's reply will not contain that descriptor (as opposed
to an empty descriptor being sent from MG to MGC).

(4) Remote without local may occur in case a one way stream is being set
up.  The MG doesn't have to be prepared to receive anything, it will
only send media.

(5) I don't quite understand Tom's question either.

Earlier in the thread there was discussion about which descriptor to use
in the first Add on the originating side.  Is Local used, or
LocalControl?  I don't think it was resolved.  In my opinion it has to
be Local.

John
--
John Segers                                  email: [email-masked]
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954