Subject: Re: Proposed Text For Media Specification]

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 3 Jan 2000 10:41:45 -0500

See comments below

> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]]
> Sent: Monday, January 03, 2000 10:31 AM
> To: Tom-PT Taylor; Brian Rosen
> Cc: ietf_megaco
> Subject: Re: Proposed Text For Media Specification]
>
>
> G'Day Brian and Tom,
>
> Negotiation is between two MGCs - I agree.
> Negotiation always starts with capability - I agree.
> There is a message from the MGC to MG to ask for capability -
> hummm....
> The MGC can be provisioned with the MGs capabilities or it
> can ask using
> the AuditCap command. Its the MGC that should order the MG to
> do certain
> task with the capabilties and the associated resources.
[br]Well, the issue we are dealing with is reservation of resources.
AuditCap doesn't get you that.  There is (currently) no way to do
it.  The proposal is that when the MG offers it's first Local/Remote
descriptor, it reserves the resources at that time.  When the MGC
subsequently modifies local/remote to reflect the results of the
negotiation, then the resources are committed (and any unused, but reserved
resources are released).

>
> for example the fast start.
> 1. The initiating MGC has a certain set of capabilities. It
> knows the MG
> can do these based on pre-provisioning or AuditCap.
[br]No, the MGC doesn't know because AuditCap doesn't reserve
resources, so the sequence:
        AuditCap (for context c1)
        AuditCap (for context c2)
        Context=c1{Add
        Context=c2(Add
can fail.  In particular, if the sequence was
        AuditCap (for context c1)
        Context=c1{Add
        AuditCap (for context c2)
        Context=c2(Add
the results returned for the second Audit Cap can be different.

> 2. Because of fast start the orginating MGC orders its MG to 'RESERVE'
> resources for reception of media streams according to the
> capabilities.
[br]This could fail as noted above.  If the MGC reserves resources for
c1, and then tries to reserve the same resource again for c2, it
may fail.

> 3. The initiating MGC using H245 negotiates with the
> terminating MGC the
> capabilities. As the terminating MGC is the 'terminating side' it does
> one of two options. The choice between options is implementation
> specific.
> option a) it decides the capability and then orders the MG to
> send media
> with a certain capability.
> option b) sends the set of capabilities (ie. overspecified properties)
> asking the MG to 'CHOOSE' one set of capabilties and immediately
> 'RESERVE' resources for the sending of media.
[br]There is no reservation really here; the MG makes a real choice,
and actually consumes the resources.

> 4. In this case the media beats the MGC-MGC negotiation. The
> originating
> side according to Faststart must expect media as soon as its send the
> embedded H245 OLC.
> 5. The originating MG detects media on one set of resources
> and NOTIFYs
> the MGC.
[br]This is not in any call flows to date and there is no event
defined for recieving media on a flow.

> 6. The MGC then does a MODIFY removing the other allocated resources.
>
> I don't believe that the negotiation between MGCs should be covered in
> Megaco. I don't Below is some proposed text that I believe most of the
> concepts discussed without going in the nuts and bolts of SDP.
[br] I've not thought through this text since I think the premise is wrong.

I think the faststart sequence is:
MGC1 sends policy to MG1 in local
MG1 responds with capability, filtered by policy, and reserves
resources
MGC1 sends capability to MGC2
MGC2 sends policy to MG2
MG2 responds with either capability, or simply makes a choice and
responds with the choice
MGC2 sends negotiated result to MGC1
MGC1 modifies MG1 with result.  Resources are committed, excess ones are
released.
Since media may arrive at MG1 prior to the last step above, MG1
must be capable of configuring itself based on what it gets.  This
is what a fast-start capable GW has to do now.

> Below is a start of a proposal for 7.1.8 Local and Remote
> Start>>>>>
> Local and Remote Descriptors contain the parameters
> describing the flows
> sent to and received from the MG. In the case where the MGC
> controls the
> originating MG. The Local Descriptor contains the parameters
> describing
> the flows received by the originating gateway and sent by the remote
> gateway. The Remote Descriptor contains the parameters
> describing flows
> sent by the originating gateway and received by the Remote gateway.
> <Add a diagram illustrating this>
>
> Local and Remote descriptors may contain sets of parameters
> to describe
> different capability sets. In the text version this is achieved by
> <<<TBD>>>. In the binary version this is achieved by <TBD>.
>
> H.248 supports three uses of the Local and Remote Descriptors between
> the MGC and MG:
> 1. The MGC shall 'fully specify' the parameters describing the flows
> associated with the descriptors. The MG shall reserve and use the
> resources specified by the MGC.
> 2. The MGC shall order the MG to 'reserve'  the resources associated
> with EACH set of parameters (ie. Capability sets) describing the flows
> associated with the descriptors. The MG shall reserve and use the
> resources specified by each set of parameters as specified by the MGC.
> In the text version this is achieved by <TBD>.
> In the binary version this is achieved by <TBD>.
> 3. The MGC shall order the MG to 'choose' the resources
> associated with
> one set of parameters (ie. Capability sets) describing the flows
> associated with the descriptors. The MG shall choose, reserve and use
> the resources specified by one set of parameters as specified
> by the the
> MGC.
> In the text version this is achieved by <TBD>.
> In the binary version this is achieved by <TBD>.
> <<< END
>
> We may also want to add some text on what descriptors and
> errors the MG
> returns in line with Tom's proposal. Is this something we can
> work with?
>
> Cheers, Christian
>
> -------- Original Message --------
>  Subject: Re: Proposed Text For Media Specification
>     Date: Thu, 23 Dec 1999 10:55:33 -0500
>     From: "Rosen, Brian" <[email-masked]>
> Reply-To: "Rosen, Brian" <[email-masked]>
>       To: [email-masked]
>
> Negotiation is always between two MGCs.  Negotiation always
> starts with
> capability.  So there is a messagefrom 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 thatdecides).  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 oneof these" and
> "here is my
> policy, tell me your capability"  is getting pretty bad.
> This is why I
> liked usingremote and local rather than sendonly or Nancy's
> vertical bar
> -- less modification to SDP syntax.Brian
>
>      -----Original Message-----
>      From: Tom-PT Taylor [mailto:[email-masked]]
>      Sent: Wednesday, December 22, 1999 7:51 PM
>      To: Rosen, Brian
>      Cc: [email-masked]
>      Subject: RE: Proposed Text For Media Specification
>      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.
>
>           -----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.
>
>           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
>
>                        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
>                > -----Original Message-----
>                > From: Tom-PT Taylor [
>                <mailto:[email-masked]>]
>                > Sent: Wednesday, December 22, 1999 10:40 AM
>                > To: Chip Sharp; Brian Rosen;
>                [email-masked]
>                > Subject: RE: Proposed Text For Media Specification
>
>                >
>                >
>                > 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.
>                >
>
>
>