Subject: Re: Washington Issue 9 - Wildcards in SDP

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 7 Dec 1999 17:28:12 -0500

Unfortunately this is an orthogonal issue to the one I raised.  Your
proposal may make it impossible to state the "send" capabilities of a given
MG.  The existing view is that Local indicates both the "receive" and the
"send" capabilities, and these may be identified separately if necessary.

I'm still looking for comment on whether we can forget about providing
anything but truly local (i.e. unsignalled) parameters in LocalControl.

> -----Original Message-----
> From: Christian Groves [SMTP:[email-masked]]
> Sent: Monday, December 06, 1999 4:02 PM
> To:   Taylor, Tom-PT [CAR:B904-I:EXCH]
> Cc:   [email-masked]
> Subject:      Re: Washington Issue 9 - Wildcards in SDP
>
> Hello Tom,
>
> We had some discussion about what the Local and Remote descriptor
> actually means and I guess the email below is trying to solve this
> issue. I was under the impression that local described the properties of
> the "received media" and that remote described the properties of the
> "transmitted media". This is how I interpret the text in the Whitepaper.
>
> Attached is a PDF on how I view the configuration.
>
> After discussion with people that have been working with H248 for quite
> awhile they were under the same impression, however other see it
> differently. I continuously get questions regarding what local and
> remote mean therefore I propose the addition of the diagram to the H.248
> protocol.
>
> I agree with your sentiments that data is being duplicated in the
> current situation. Local should have the properites/characteristics of
> the "received media". Remote should have the properties/characteristics
> of "sent media". This would also align the text and binary versions.
>
> Cheers, Christian
>
>
>
> Tom-PT Taylor wrote:
> >
> > There is an issue concerning the respective contents of LocalControl and
> > Local which was nearing resolution before I lost my E-mail contact with
> the
> > world.  To make the nature of this issue clear I will review how we do
> media
> > negotiation now, then make a proposal for how it can be simplified.
> >
> > As stated in section 7.1.7 of the H.248v12 document,
> >
> > "The LocalControl Descriptor contains the Mode parameter and properties
> of a
> > termination (defined
> > in Packages) that are stream specific, and are of interest between the
> MG
> > and the MGC. Values of
> > properties may be underspecified as in Section 7.1.5."
> >
> > In the next section, Local is defined as follows:
> >
> > "The Local and Remote Descriptors contain the parameters describing the
> > flows sent to and received
> > from the MG, and are of interest between two MGs....Local is the
> capability
> > of the local MG and is typically sent from MG to MGC, and subsequently
> used
> > as part of a capability negotiation between two MGCs."
> >
> > In the MGCP tradition, we have assumed that LocalControl provides
> guidance
> > on codec selection, amongst other things.  That is, the MGC sends down
> > policy in LocalControl, the MG returns capabilities within the confines
> of
> > that policy, and the MGC passes these to the far end via whatever
> signalling
> > system it is using.
> >
> > Unfortunately, even ignoring the binary vs. text issue this seems to
> imply a
> > lot of double defining of codepoints.  Here are two concrete examples
> based
> > on the "Network" package in Annex E, section E.9:
> >
> > (1) The Network package specifies a "Network type" property which can be
> > used to indicate the transport stack to be used.  This information is
> echoed
> > in the network type as given on the c= line of Local, plus further stack
> > details as given on the m= line.  Two encodings for the same
> information.
> >
> > (2) The Network package defines "Preferred Encoding" and "Preferred
> > Decoding" properties.  These are echoed in the RTP payload type in the
> m=
> > line, plus, possibly, some a=rtpmap entries.  Two encodings for the same
> > information.
> >
> > We should not be doing everything twice over (plus the binary encoding).
> > This is going to be inefficient to administer and confusing to use.  I
> > propose two alternatives:
> >
> > Either we use the same encoding for any information which will be common
> to
> > LocalControl and Local.
> >
> > or
> >
> > We make things even simpler and eliminate the redundancy.  The only
> > information which would go into LocalControl would be properties of
> strictly
> > local interest (i.e. which would not be signalled to the far end).
> >
> > The implication of this second alternative is that Local as sent down
> from
> > the MGC to the MG will be underspecified (not really something new).
> What
> > will be new is the additional information that Local will contain
> compared
> > with MGCP practice.  As an example, there will be a c= line indicating
> the
> > transport network type and possibly even the address type, but no actual
> > address.  There will be an m= line specifying the medium for that
> stream,
> > the rest of the transport stack, and the coding preferences, but that
> line
> > won't have a port number.  Thus we will need placeholders (wildcards?)
> > within the SDP to indicate the information to be filled in by the MG.
> >
> > Tom Taylor
> > Advisor -- IPConnect Standards
> > E-mail: [email-masked] (internally, Tom-PT Taylor)
> > Phone and FAX: +1 613 736 0961 << File: localremote_des.pdf >>