Subject: Re: Proposed Text For Media Specification

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

We have a basic disconnect.  In my discussion the other day ("Re: Annex E
edits to Network, RTP, and DS0 pkgs", Sunday 19 Dec'99), I said there were
two alternative interpretations of the exchanges between the MGC and the MG.
I'll quote their description:

<Begin quote>
Christian raises the good question of whether Megaco/H.248 should be a
negotiation protocol.  This is a tricky point.  For a start, there is a
difference between what happens between the MGC and the MG at the
originating end and what happens at the terminating end.  Speaking of the
originating end only, there are two ways to look at the exchange between the
MGC and the MG:

(1) The MGC provides "policy guidance" to the MG.  The MG returns its
current capabilities constrained by the policy envelope.  The MGC can take
the information provided by the MG and use it to shape the message sent to
the far end.

(2) The MGC reserves a set of resources in the MG, subject to the outcome of
negotiation with the far end.
<End quote>

In my earlier note I concluded that the second point of view was more
realistic.  You are pushing for the first point of view, and as I also said
earlier, it makes quite a difference both in content and in procedures.  We
may have to wait until after the holidays to get a feeling for the broader
consensus on this one.

I will attempt some detailed responses to your points, beyond this
fundamental disagreement.

I see you've just sent another message offering further basis for
negotiation, so I'll bear that in mind here.

> -----Original Message-----
> From: Rosen, Brian [SMTP:[email-masked]]
> Sent: Wednesday, December 22, 1999 9:05 AM
> To:   Taylor, Tom-PT [CAR:B904-I:EXCH]
> Cc:   [email-masked]
> Subject:      RE: Proposed Text For Media Specification
>
> 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]
>
>
>
> > -----Original Message-----
> > From: Tom-PT Taylor [mailto:[email-masked]]
> > Sent: Tuesday, December 21, 1999 9:27 PM
        [[TomT]]  ...
> >
> > <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.
> This is confusing because the MG can offer multiple alternatives
> that are subsequently negotiated and then narrowed to a single
> choice by the negotiation.
        [[TomT]]
        Here's the fundamental disconnect.  In the view I proposed, the MG
doesn't offer anything -- it selects from the alternatives offered by the
MGC.

> 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.
>
> > (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
> I feel, as Nancy does, that it is preferable to use "|" in
> the m= line rather than recvonly and sendonly.
        [[TomT]]
        Implies a more drastic change to SDP.  Of course, wildcards and
UNSPECIFIED are already going beyond vanilla SDP.
>
> > (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".
> 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.
        [[TomT]]
        But if the MGC specifies asymmetric encoding from the outset (e.g.
the a=sendonly case above) it will either have to omit the "c=" line for
that media-level description or use the placeholder, and in any event it
will have to use the placeholder for the far-end port in the "m=" line.
>  I don't think there is
> a case where the MG sends remote unless the MGC audits.
>
> > (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:
> 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.
        [[TomT]]
        The problem is that sometimes you do need multiple encodings (e.g.
the tones encoder plus a voice encoder, or G.711 as a fallback in
alternating text/voice).

> >  - 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.
> 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.
        [[TomT]]
        The tones encoder is a clear example, and mixed text/voice
conversation will be another.  I absolutely agree that there should be only
one session descriptor in the final negotiated local, and say so in rule
(1).  Here we are talking about multiple payload types on the same "m="
line.

> >
> > (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.
> 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.
        [[TomT]]
        This is referring to the thought that terminations are associated
with bearers, on which point I believe we are agreed.  If so, then you have
to have some means of expressing that for a provisioned termination at
least, and the natural way is through a property in TerminationState.

        Medium is stated on the "m=" line.  What I'm saying is that for a
given streamID within a given context, the MG enforces
implementation-dependent consistency requirements on the parameter
immediately following "m=".
>
> > (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".
> "Offered" confused me.  The MGC sends policy, the MGC offers capability.
> Better to use "any of the requested alternatives"
        [[TomT]]
        Comes back to our basic disconnect.  In the view I documented, the
MGC offers alternatives and the MG selects one.
>
> > (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.
> Same comment, and the comment above on multiple sessions.
>
> > 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".
> 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.
        [[TomT]]
        Sounds like Remote is unnecessary if that is the case.
>
> > <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: Nachum Frid <[email-masked]>
Date: Wed, 22 Dec 1999 19:14:37 +0200

The Megaco trasport can implement  either UDP or TCP.   When using TCP
a single port is going to be used for transport of transactions? ,  or may
be its better  to use  multiple ports that will be dynamically allocated for
every new Context ?