Subject: Proposed Text For Media Specification

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 21 Dec 1999 21:26:41 -0500

I am proposing the following changes to section 7.1.8 "Local and Remote
Descriptors", in line with the apparent agreement of the WG that aside from
purely local matters the MGC should assert its control over media via the
Local and Remote descriptors.

Delete the second paragraph entirely.

Replace it with the following text:

<Begin replacement text>

The Local descriptor reserves resources on the local MG for media reception.
The following rules apply to the use of the Local Descriptor:

(1) Each session description contained within the Local Descriptor specifies
an alternative which the MG may use for encoding and decoding the given
stream.  The MG must choose a single alternative from amongst those offered.

(2) Any one session description MUST contain either one or two media-level
descriptions.  If there are two media-level descriptions, one applies to
received media (media decoding), the other to transmitted media (media
encoding).  The direction of media flow for a given media description is
indicated by the presence of the "a=recvonly" or "a=sendonly" attribute
respectively, or the Annex C equivalent.  If there is just one media-level
description, it MAY contain a directionality attribute; if it does not, the
media flow is assumed to be symmetric.  A media-level description pertaining
to an

(3) Within any session description, the MGC may use the UNSPECIFIED
placeholder [proposed to be "-" for text encoding] to indicate a parameter
value which can only be assigned by the remote device.  The MG must search
for the corresponding value within the Remote Descriptor and substitute its
value.  It is an error for the MGC to enable a flow in either direction
(through its setting of the Mode parameter in LocalControl) before all
UNSPECIFIED values have been resolved.  Upon detection of such an error the
MG must reject the transaction and return the error indication 441, "Missing
RemoteDescriptor".

(4) Within the session description which the MG chooses to support, if
multiple media encodings are specified, the MG must reserve the resources to
handle all of them.  To be more specific, it must reserve resources in
accordance with the following assumptions:
 - for transmitted media content the encodings are listed in decreasing
order of preference.  If a given encoding is applicable only to a subset of
media content (e.g. the new tones payload type) then less-preferred
encodings will also be used as required to process the outgoing flow.
 - for received media content, the incoming flow may switch at any time
between any of the specified encodings.

(5) The MGC may use the CHOOSE wildcard in place of most parameter values,
with the specific exception of network type and medium type.  (Network type
MUST always be the same as that indicated in the Network Type property in
TerminationState.  Depending on the implementation, the MG will require that
the medium type for a given stream be the same for all terminations in the
same context, or may allow certain implicit transformations such as
text-to-voice.)  The MG is free to assign any value to the wildcarded item
which is consistent with the remainder of the media description.  It must
return the Local Descriptor with the assigned values in its response.

(6) If the MG is unable to reserve sufficient resources to support any of
the offered alternatives it must reject the transaction, returning error
510, "Insufficient resources".

(7) If the MG successfully reserves resources for one of the offered
alternatives, and the Local Descriptor originally supplied by the MGC was
under-specified either through use of the CHOOSE wildcard or through
omission of attributes for which the MG is able to supply default values,
the MG must return a completed Local Descriptor in its response, showing the
values which it has supplied.  This may require the use of one or more
"a=fmtp..." attribute lines or the Annex C equivalent to show additional
format parameters individually for each media encoding within the session
description.

The Remote Descriptor describes resources reserved in the remote device.
The MGC may initially omit the Remote Descriptor, but must ensure that any
UNSPECIFIED values are resolved before the affected flows are activated, as
mentioned in rule (3) above.  It is an error for the MGC to specify
inconsistent Local and Remote Descriptors.  If the MG detects such an error
it must reject the transaction, returning error ??? [need one].

The MG uses the Remote Descriptor for two purposes:
 - to resolve any UNSPECIFIED values present in the Local Descriptor
 - to add details of specification (such as additional attribute values for
a given encoding) which are not present in the Local Descriptor provided by
the MGC.
It is possible that the additional detail provided by the Remote Descriptor
creates a configuration which cannot be supported by the MG, even though it
can support the Local Descriptor.  In this case, as in rule (6) above, the
MG rejects the transaction with error 510, "Insufficient resources".

<End of replacement text>

Tom Taylor
Advisor -- IPConnect Standards
E-mail: [email-masked] (internally, Tom-PT Taylor)
Phone and FAX: +1 613 736 0961

---

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 21 Dec 1999 21:33:19 -0500

Ooops, in the first sentence that should be "...for media reception and
transmission."

> -----Original Message-----
> From: Taylor, Tom-PT [CAR:B904-I:EXCH]
> Sent: Tuesday, December 21, 1999 9:27 PM
> To:   [email-masked]
> Subject:      Proposed Text For Media Specification
>

---

From: Chip Sharp <[email-masked]>
Date: Tue, 21 Dec 1999 22:11:38 -0800

This would totally change the operation of H.248 from the current operation
in which the MGC never sends a Local Descriptor.  Sounds like you want to
use Local Descriptor to send commands to the MG.

Chip

>Phone and FAX: +1 613 736 0961

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.
--------------------------------------------------

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 22 Dec 1999 07:52:36 -0500

Yes, several of us have been discussing this.

It stems from the prior paradigm where:
1. The MGC sent policy to the MG in localcontrol
2. The MG sent capability to the MGC in local
3. The MGC sent negotiated decision to the MG in local

To do this, it is necessary to duplicate all the parameters you
might have policy and/or capability in both local and localcontrol.
This is silly.  So Tom proposed that we change the sequence
to:
1. The MGC sends policy to the MG in local
2. The MG sent capability to the MGC in local
3. The MGC sent negotiated decision to the MG in local
Restricting all the policy/capability parameters to local.

It means a change to the SDP that the MG/MGC exchange to allow
specification of choice, and also to deal with asymmetric parameters
that H.245 can express.

Brian
> From: Chip Sharp [mailto:[email-masked]]
> Sent: Wednesday, December 22, 1999 1:12 AM
> To: [email-masked]
> Subject: Re: Proposed Text For Media Specification
>
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 22 Dec 1999 09:05:26 -0500

I think this is going in the right direction.

I think we want to be explicit that:
        1. The MGC sends Local with its policy in an Add
        2. The MG replies with Local set to it's capability,
                as modified by policy in the response to the Add
        3. The MGC negotiates with its counterpart
        4. The local MG gets the negotiated result of its capability
           in local, and the negotiated result of the other side's
           capability in remote, both in a Modify.

I interspersed some comments below.

Brian
------------
Brian Rosen, Principal Engineer
Marconi (Formerly FORE Systems)
1000 FORE Drive, Warrendale, PA 15086
(724) 742-6826  mailto:[email-masked]

> From: Tom-PT Taylor [mailto:[email-masked]]
> To: Brian Rosen
> Cc: [email-masked]
This is confusing because the MG can offer multiple alternatives
that are subsequently negotiated and then narrowed to a single
choice by the negotiation.  How about:
  Each session description contained with the Local Descriptor
  specifies an alternative that which may be used for encoding
  and decoding.  If supplied to the MG by the MGC, alternatives
  indicate MGC preference, in order.  If supplied by the MG to
  the MGC alternatives indicate capability by the MG.  Prior to
  establishment of the actual stream, Local must contain exactly
  one session description.

> media flow is assumed to be symmetric.  A media-level
I feel, as Nancy does, that it is preferable to use "|" in
the m= line rather than recvonly and sendonly.

> MG must reject the transaction and return the error
I'm a little confused by this.  Remote is the other side's negotiated local.
I don't think there is a case where the
MGC sends remote unless it's negotiated.  I don't think there is
a case where the MG sends remote unless the MGC audits.

> accordance with the following assumptions:
How about "any of them"?  The most common case, as we all know
is G.711, G.723, G.729a or something.  You need to reserve
resources to handle any one of them, not all of them simultaneously.

> between any of the specified encodings.
While I understand that this is possible, right now there is
no support for such things in SDP or for that matter in H.323 or SIP -
multiple codecs with run time switching between them.  I argue
this issue should be deferred, and there should only be ONE
session descriptor in the final negotiated local.

> return the Local Descriptor with the assigned values in its response.
First of all, if network type always the same, then we don't need it in
LocalControl or TerminationState, it can be in Local.  Secondly,
medium is not defined anywhere that I know of.

> 510, "Insufficient resources".
"Offered" confused me.  The MGC sends policy, the MGC offers capability.
Better to use "any of the requested alternatives"

> format parameters individually for each media encoding within
Same comment, and the comment above on multiple sessions.

> MG rejects the transaction with error 510, "Insufficient resources".
I don't see how this could happen unless negotiation was in error.
Remote had better not have anything not in Local.  It indeed would
be an error if it did.

---

From: Chip Sharp <[email-masked]>
Date: Wed, 22 Dec 1999 09:40:13 -0800

>         1. The MGC sends Local with its policy in an Add

1. The MGC sends LocalControlDescriptor with its policy in an Add.

>                 as modified by policy in the response to the Add

The MG replies with a session description in LocalDescriptor in response to
Add defining what it can receive.

>            capability in remote, both in a Modify.

The MGC sends the negotiated result of what the remote end can receive in
the RemoteDescriptor in a Modify.

---

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 22 Dec 1999 10:39:48 -0500

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.

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 22 Dec 1999 10:45:54 -0500

In defense of the position I would point out that when the
MG supplies it's version of local it is BEFORE negotiation
takes place.  This has to be true because it has to reserve
resources and report what it could support.  The MGC must take
that set of alternatives and negotiate with its opposite MGC.
The result of that negotiation has to be one, agreed upon session
description that both MGs can support.

Given that, I think the MG must offer a set of alternatives.

Brian
> Sent: Wednesday, December 22, 1999 10:40 AM
> To: Chip Sharp; Brian Rosen; [email-masked]
> Subject: RE: Proposed Text For Media Specification
>
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 22 Dec 1999 15:10:20 -0500

In my view each end independently has policy, each end independently has
capability.
Each end independently applies policy to capability and ends up with an
ordered list
of candidates.  The negotiation is then to select the first candidate that
both ends
can support.  This results in a single answer, which is communicated to both
sides.

Suppose the originating MG can do G.711, G.723 and G.729.   The policy of
the the MGC
is G.729, then G.726, then G.711, it won't allow G.723.  Suppose the
terminating end MG has the same capability but the policy at its MGC is
G.711 then G.726, then G.729.

So the originating MGC sends 729, 726, 711, the originating MG responds 729,
711.
The terminating MGC sends 711, 726, 729, the terminating MG responds 711,
726, 729.
The negotiation occurs.  In this case the negotiation would result in 711,
and both
ends would set local and remote to 711.  Note that different MGC-MGC
protocols would have different rules on how negotiation proceeded, but all
of them would start with an ordered list of possibles, eliminate the ones
that only one side can support, and select among the remaining ones.

I'm a little bothered by the send policy, get capability.  It seems
backwards to me;  if I were
designing the system, I might be inclined to get a complete capability,
filter it by policy and
then negotiate the result.  However, the MG has to reserve resources for the
worst case of the alternatives it allows.  Therefore, it wants to know the
policy so that it does not reserve resources for options the MGC would not
allow.  On the other (other) hand, making the
MG enforce MGC policy also seems wrong - the MGC should enforce it's own
policy.
So, I'd accept the idea that the MG simply states network, nothing else, the
MG responds with capability.  The MGC filters that with policy, negotiates
it, and then sends the single
result to the MG.  The way we have it is okay, and as I observe, may leave
the MG with
more available resource.

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Wednesday, December 22, 1999 11:48 AM
To: Rosen, Brian
Cc: [email-masked]
Subject: RE: Proposed Text For Media Specification

Could we take this one step further toward concreteness?  A couple of points
have been bothering me: how does the MG at the originating end know which
alternatives to offer, and at the terminating end what does the MG do with
Remote?  Furthermore, how does the MGC tell the MG: "This is what you're
going to use; we're not negotiating any more."?

I've also realized that unless both send and receive capabilities can be
expressed in the same descriptor, there is no way for the originating MG at
least to express joint capabilities for asymmetric connections.  We may be
able to live without this.  Certainly the H.323 crowd would prefer to do so,
since H.245 and H.323 fastStart both separate capabilities by direction of
flow.

These are my answers to my own questions, starting from the premise that
Local describes received flows, Remote describes transmitted flows.

(1) At the originating end, the MGC may supply a set of alternative session
descriptions (mutually exclusive alternatives) and within each a list of one
or more payload types.  Here's the key point: the MG in its response is
constrained by the list of payload types -- it can't offer any not listed in
the first place by the MGC.  However, it can offer alternatives for detailed
parameters associated with those payload types.  This is especially
necessary with video, where the list of possible alternatives can go on
forever.  We'll have to think a bit about the syntax for offering these
alternatives -- yet more session descriptions or ranges or whatever.

(2) At the terminating end, the MGC takes the signalled send and receive
capabilities from the far end.  (If the signalling is via SDP and
capabilities are not broken out by direction, symmetric flow capabilities
are assumed.)  The terminating MGC may filter out non-starters from its
policy viewpoint, then it will build Local and Remote from what remains.

Now the question is what rule the MG follows to evaluate what is presented.
First off, I assume we want the MG to choose a single alternative at this
point.  How is that indicated by the MGC?  I would favour an explicit
parameter in LocalControl rather than a rule like "If Remote is present,
choose a single alternative rather than presenting alternatives.".

        -----Original Message-----
From:   Rosen, Brian [SMTP:[email-masked]]
Sent:   Wednesday, December 22, 1999 10:46 AM
To:     Taylor, Tom-PT [CAR:B904-I:EXCH]
Cc:     Megaco (E-mail)
Subject:        RE: Proposed Text For Media Specification

        Brian
> From: Tom-PT Taylor [ mailto:[email-masked]
<mailto:[email-masked]> ]

---

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 22 Dec 1999 18:50:35 -0600

I've had to think about this a bit, because I have a couple of problems with
it.  The main problem is that there doesn't seem to be any point of
convergence -- the terminating MG sends back its version of Local and Remote
to its MGC "and then negotiation occurs" (your words).  Negotiation between
what entities?  Does there now have to be another round of messaging to tell
the MGs what the MGCs have decided, at the terminating end as well as at the
originating end?

Actually, I think I can leave this up to the implementation.  We can simply
have a rule that the MG echoes back that subset of whatever the MGC proposes
that the MG can support.  If I want to save a message by making the final
decision in the terminating MGC BEFORE sending a message down to the MG
that's my business as an MGC implementor.

On your concern about getting capability after policy is set: you can always
do an AuditCapability on the termination to start with if you want to be
perfect.  The reason the MGC imposes policy has to do with the signalling it
has received, or resources it is trying to husband.  Knowing more precisely
the instantaneous capability of the MG isn't going to change those factors.

> Sent: Wednesday, December 22, 1999 3:10 PM
> can support.  This results in a single answer, which is communicated to
> both sides.
>
> So the originating MGC sends 729, 726, 711, the originating MG responds
> 729, 711.
> then negotiate the result.  However, the MG has to reserve resources for
> the worst case of the alternatives it allows.  Therefore, it wants to know
> the policy so that it does not reserve resources for options the MGC would
> not allow.  On the other (other) hand, making the
> So, I'd accept the idea that the MG simply states network, nothing else,
> the MG responds with capability.  The MGC filters that with policy,
> negotiates it, and then sends the single
>       Could we take this one step further toward concreteness?  A couple
> of points have been bothering me: how does the MG at the originating end
> know which alternatives to offer, and at the terminating end what does the
> MG do with Remote?  Furthermore, how does the MGC tell the MG: "This is
> what you're going to use; we're not negotiating any more."?
>
>       I've also realized that unless both send and receive capabilities
> can be expressed in the same descriptor, there is no way for the
> originating MG at least to express joint capabilities for asymmetric
> connections.  We may be able to live without this.  Certainly the H.323
> crowd would prefer to do so, since H.245 and H.323 fastStart both separate
> capabilities by direction of flow.
>
>       These are my answers to my own questions, starting from the premise
> that Local describes received flows, Remote describes transmitted flows.
>
>       (1) At the originating end, the MGC may supply a set of alternative
> session descriptions (mutually exclusive alternatives) and within each a
> list of one or more payload types.  Here's the key point: the MG in its
> response is constrained by the list of payload types -- it can't offer any
> not listed in the first place by the MGC.  However, it can offer
> alternatives for detailed parameters associated with those payload types.
> This is especially necessary with video, where the list of possible
> alternatives can go on forever.  We'll have to think a bit about the
> syntax for offering these alternatives -- yet more session descriptions or
> ranges or whatever.
>
>       (2) At the terminating end, the MGC takes the signalled send and
> receive capabilities from the far end.  (If the signalling is via SDP and
>       Now the question is what rule the MG follows to evaluate what is
> presented.  First off, I assume we want the MG to choose a single
> alternative at this point.  How is that indicated by the MGC?  I would
> favour an explicit parameter in LocalControl rather than a rule like "If
> Remote is present, choose a single alternative rather than presenting
> alternatives.".
>
>
>
>       > From: Tom-PT Taylor [ <mailto:[email-masked]>]

---

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 23 Dec 1999 07:33:41 -0600

It's possible to make the distinction between "choose one" (which would
certainly make sense at an MG at the terminating end), and "reserve all of
these".  "Choose one" is expressed by providing separate session
descriptions (with separate "v=0" headers or the ASN.1 equivalent) for the
alternatives.  "Reserve all" is expressed by listing everything in one
session description.  Of course, you can do both, listing mutually exclusive
sets of alternatives e.g. G.711 vs. {G.723.1 + TONES}.

> From: John Segers [SMTP:[email-masked]]
> Sent: Thursday, December 23, 1999 3:21 AM
> Tom,
> Faststart adds a twist to all of this.  If the originating MGC (after
> determining MG capabilities) allows multiple options for codec, the
> originating MG has to be able to receive media according to any of
> these: the far end may choose one of the options presented and start
> sending media.  You can't assume that the MGC has the opportunity to
> send a Modify to the MG before the first media packets arrive.
>
> In the megaco syntax it should be possible to distinguish between an MGC
> telling an MG to "choose one of the options a, b, or c" and "reserve
> resources for options a, b, and c".  The former is an MGC enforcing
> policy on the local MG, the latter is for support of faststart.  I
> assumed that for both cases the MGC already knows what the MG could do.
>
> Cheers,
>
> John
>
> > Tom-PT Taylor wrote:
> >
> > Could we take this one step further toward concreteness?  A couple of
> > points have been bothering me: how does the MG at the originating end
> > know which alternatives to offer, and at the terminating end what does
> > the MG do with Remote?  Furthermore, how does the MGC tell the MG:
> > "This is what you're going to use; we're not negotiating any more."?
> >
> > I've also realized that unless both send and receive capabilities can
> > be expressed in the same descriptor, there is no way for the
> > connections.  We may be able to live without this.  Certainly the
> > H.323 crowd would prefer to do so, since H.245 and H.323 fastStart
> > both separate capabilities by direction of flow.
> >
> > session descriptions (mutually exclusive alternatives) and within each
> > a list of one or more payload types.  Here's the key point: the MG in
> > its response is constrained by the list of payload types -- it can't
> > offer any not listed in the first place by the MGC.  However, it can
> > offer alternatives for detailed parameters associated with those
> > payload types.  This is especially necessary with video, where the
> > list of possible alternatives can go on forever.  We'll have to think
> > a bit about the syntax for offering these alternatives -- yet more
> > session descriptions or ranges or whatever.
> >
> > receive capabilities from the far end.  (If the signalling is via SDP
> > and capabilities are not broken out by direction, symmetric flow
> > capabilities are assumed.)  The terminating MGC may filter out
> > non-starters from its policy viewpoint, then it will build Local and
> > Remote from what remains.
> >
> > favour an explicit parameter in LocalControl rather than a rule like
> > "If Remote is present, choose a single alternative rather than
> > presenting alternatives.".
> >
> --
> 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

---

From: Nancy-M Greene <[email-masked]>
Date: Thu, 23 Dec 1999 10:16:27 -0500

> 1. The MGC sends LocalControlDescriptor with its policy in an Add.
[Nancy] Chip, in fact, we are proposing that the MGC sends policy in an Add
to the MGC in the LocalDescriptor. The LocalControlDescriptor will, in the
new proposal, only contain properties of interest between the MGC and the MG
(mode, jitter, ds0/gain, ds0/ec). sdp (or the tag-value binary from Annex C)
in the LocalDescriptor will contain information that eventually will be sent
to the other MG. We decided to have the MGC send the policy and the
preferred order of codecs it wants the MG to choose from as a list of sdp
blocks in the LocalDescriptor. Since the MGC does not have the IP address
nor the port, those fields in the sdp will be marked with "$".

We are proposing this for two reasons: 1) because there are MANY parameters
an MGC may want to dictate policy on and we don't want to repeat them in
both the sdp and in LocalControl, and 2) the way we had it defined in
LocalControlDescriptor was flawed - for example, ptime needs to be
associated with a specific codec. While the LocalControl method may have
worked,  when we get the ATM package defined, we do NOT want to repeat in
LocalControl all the properties to be added to sdp for setting up ATM. When
we have the ATM package, and an example call flow, the advantages of the new
approach will be more apparent (hint, hint... to the ATM guys....)

See Tom's message sent Dec 14/99 with subject "RE:Annex E edits to Network,
RTP, and DS0 pkgs".

Nancy
--------------------------------------------------------------------------
Nancy M. Greene
Internet & Service Provider Networks, Nortel Networks
T:514-271-7221 (internal:ESN853-1077) E:[email-masked]

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 23 Dec 1999 10:38:35 -0500

I don't think there is ever a case of the MGC asking the MG to choose
something
in local or remote.  It may ask for a "fill in the blank", and it may ask
for
capability.  The MG responds with what it knows, but in this case, it
doesn't choose.
It does have to reserve resources for any of the possibilities it offers.

The MGC negotiates, then specifies what must happen.

Brian

> From: John Segers [mailto:[email-masked]]
> >      > between the roles of Local and Remote, and I think
> we'll have a
> >      good
> >      > sensible result.
> >      >
>
> --

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 23 Dec 1999 10:55:33 -0500

Negotiation is always between two MGCs.  Negotiation always starts with
capability.  So there is a message
from MGC to MG to ask for capability.  It can express policy, but it doesn't
have to.  Then the two MGCs negotiate.
Then both MGCs tell their respective MGs what the result is.  One end does
that right away (the end that
decides).  The other end has to wait for the message from the distant MGC
before it can tell its MG.  In fast start,
the terminating MG is the decision maker, so it gets capability from its MG,
decides based on what it's MG can do, and what the originating MGC said the
originating MG can do, and tells it's MG what to do.

We are bending SDP pretty hard.  Having yet another bend so that you can
differentiate between "choose one
of these" and "here is my policy, tell me your capability"  is getting
pretty bad.  This is why I liked using
remote and local rather than sendonly or Nancy's vertical bar -- less
modification to SDP syntax.

Brian

        -----Original Message-----
From:   Rosen, Brian [SMTP:[email-masked]]
Sent:   Wednesday, December 22, 1999 3:10 PM
To:     Taylor, Tom-PT [CAR:B904-I:EXCH]
Cc:     [email-masked]
Subject:        RE: Proposed Text For Media Specification

        In my view each end independently has policy, each end independently
has capability.
Each end independently applies policy to capability and ends up with an
ordered list
of candidates.  The negotiation is then to select the first candidate that
both ends
can support.  This results in a single answer, which is communicated to both
sides.

        MG enforce MGC policy also seems wrong - the MGC should enforce it's
own policy.
So, I'd accept the idea that the MG simply states network, nothing else, the
MG responds with capability.  The MGC filters that with policy, negotiates
it, and then sends the single

        result to the MG.  The way we have it is okay, and as I observe, may
leave the MG with
more available resource.

Brian

        -----Original Message-----

        Could we take this one step further toward concreteness?  A couple
of points have been bothering me: how does the MG at the originating end
know which alternatives to offer, and at the terminating end what does the
MG do with Remote?  Furthermore, how does the MGC tell the MG: "This is what
you're going to use; we're not negotiating any more."?

        I've also realized that unless both send and receive capabilities
can be expressed in the same descriptor, there is no way for the originating
MG at least to express joint capabilities for asymmetric connections.  We
may be able to live without this.  Certainly the H.323 crowd would prefer to
do so, since H.245 and H.323 fastStart both separate capabilities by
direction of flow.

        (1) At the originating end, the MGC may supply a set of alternative
session descriptions (mutually exclusive alternatives) and within each a
list of one or more payload types.  Here's the key point: the MG in its
response is constrained by the list of payload types -- it can't offer any
not listed in the first place by the MGC.  However, it can offer
alternatives for detailed parameters associated with those payload types.
This is especially necessary with video, where the list of possible
alternatives can go on forever.  We'll have to think a bit about the syntax
for offering these alternatives -- yet more session descriptions or ranges
or whatever.

                -----Original Message-----
From:   Rosen, Brian [SMTP:[email-masked]]
Sent:   Wednesday, December 22, 1999 10:46 AM
To:     Taylor, Tom-PT [CAR:B904-I:EXCH]
Cc:     Megaco (E-mail)
Subject:        RE: Proposed Text For Media Specification

                Brian
> From: Tom-PT Taylor [ < mailto:[email-masked]
<mailto:[email-masked]> >]