Subject: RE: Annex C Descriptor Assignments

From: "Tom-PT Taylor" <[email-masked]>
Date: Fri, 11 May 2001 12:57:00 -0400

It looks like I should completely rewrite my contribution to express exactly
this.  Any other comments?  (Christian may be in the air already, in which
case I'll talk to him in Geneva next week.)

> -----Original Message-----
> From: Troy Cauble [mailto:[email-masked]]
> Sent: Friday, May 11, 2001 10:30 AM
> To: Taylor, Tom-PT [NORSE:B881:EXCH]
> Cc: 'Rosen, Brian'; 'megaco'
> Subject: Re: Annex C Descriptor Assignments
> 
> 
> 
> Yes!
> 
> Annex C  -- binary only -- LD & RD only.
> SDP -- text only -- LD & RD only.
> Packages -- binary AND text -- NOT in LD & RD.
> 
> It's great that Tom found so few exceptions.  
> That makes it feasible to move them out into 
> packages.
> 
> I would like to drop the "Package 0" terminology though.
> The word "package" implies many things that Annex C is not.
> 
> -troy
> 
> 
> > Tom-PT Taylor wrote:
> > 
> > Given my findings, I would agree with you.  Let's see what 
> other people have
> > to say.
> > 
> > > -----Original Message-----
> > > From: Rosen, Brian [mailto:[email-masked]]
> > > Sent: Friday, May 11, 2001 9:58 AM
> > > To: Taylor, Tom-PT [NORSE:B881:EXCH]; 'megaco'
> > > Subject: RE: Annex C Descriptor Assignments
> > >
> > >
> > > Before we deal with the details of this, I question the premise:
> > >   I think that Annex C ONLY is used in
> > >       binary encoding  and
> > >       in local and remote (NOT localControl or TerminationState)
> > > I think the I-G might state that better.
> > > I think that if there are some things that don't belong in remote
> > >   and local, they should be removed and possibly made part of
> > > a package,
> > >   because you don't use Annex C in LocalControl
> > >
> > > Brian
> > >
> > >
> > >
> > >
> > >
> > > Here is the contribution to SG 16 I've drafted on the subject
> > > of descript=
> > > or
> > > assignments for the Annex C properties.
> > >
> > > TITLE:        Descriptors For Megaco/H.248 Annex C Properties
> > > ___________________
> > >
> > >
> > > INTRODUCTION
> > >
> > > Megaco/H.248 Annex C defines a set of properties relating to
> > > media stream=
> > > s.
> > > As such, these properties may appear:
> > > =B7   in the LocalControl descriptor, if they are local
> > > interest only, or
> > > =B7   in the Local and Remote descriptors, if they must 
> be coordinated
> > > between the local and remote Media Gateways.
> > >
> > > Megaco/H.248 Annex C currently fails to indicate which
> > > alternative applie=
> > > s
> > > to each of the properties specified within the Annex.  This
> > > contribution
> > > argues that the H.248 Implementor's Guide should be updated
> > > to reflect su=
> > > ch
> > > an assignment.  The contribution goes on to derive principles
> > > for making =
> > > the
> > > assignment decision, and then applies those principles to
> > > derive a detail=
> > > ed
> > > set of  descriptor assignments for all of the properties 
> in the Annex.
> > >
> > > =20
> > >
> > > NEED FOR A STANDARDIZED PROPERTY ASSIGNMENT
> > >
> > > This section presents a semantic and a syntactic argument for
> > > standardizi=
> > > ng
> > > the assignment of properties to descriptors in Annex C.  At
> > > the semantic
> > > level, it is essential that the assignment to descriptors be
> > > the same for=
> > >  a
> > > given property, regardless of the H.248 protocol encoding.
> > > Otherwise one
> > > encounters a semantic mismatch between encodings, such that
> > > with respect =
> > > to
> > > a given property asymmetric flow descriptions are possible in
> > > one encodin=
> > > g
> > > and not the other.  Such a mismatch may be introduced by
> > > general usage or=
> > >  by
> > > explicit adoption of Annex C properties in standards created
> > > by bodies ot=
> > > her
> > > than the IETF Megaco Working Group or Study Group 16.
> > >
> > > At the syntactic level, assignment of specific properties 
> to specific
> > > descriptors simplifies parser construction by adding 
> predictability to
> > > message construction.
> > > A final argument in favour of adding explicit descriptor
> > > assignments is t=
> > > hat
> > > Annex C, as "Package 0", should conform as much as possible to the
> > > documentation rules for packages.  This includes 
> documentation of the
> > > descriptor to which each property should be assigned.
> > >
> > > ASSIGNMENT PRINCIPLES
> > > =20
> > > The basic criterion for descriptor assignment was indicated in the
> > > introduction: whether or not the property concerned must be
> > > coordinated w=
> > > ith
> > > the remote Media Gateway.
> > > However, some borderline cases will require the use of
> > > subsidiary criteri=
> > > a.
> > > The first such criterion was suggested in the previous
> > > section: assurance
> > > that the assignment is the same for both text and binary (Annex C)
> > > encodings.  Because the text encoding for the Local and
> > > Remote descriptor=
> > > s
> > > is tied to SDP (RFC 2327), this means that at the very least
> > > the mandator=
> > > y
> > > properties found in RFC 2327 should  be assigned to the Local
> > > and Remote
> > > descriptors rather than LocalControl.  Properties which are
> > > optional in S=
> > > DP
> > > may be placed in LocalControl if this makes sense, but the
> > > assignment mus=
> > > t
> > > be the same in both the text and the binary encodings.
> > >
> > > There is a further possible criterion: is there a potential
> > > requirement  =
> > > for
> > > a given property to have a different value for each direction
> > > of flow, an=
> > > d
> > > will it be technically feasible to meet that requirement? 
>  If so, the
> > > property should be assigned to Local/Remote rather than 
> LocalControl.
> > >
> > > DETAILED ASSIGNMENTS
> > >
> > > The following table proposes detailed assignments for the Annex C
> > > properties.  The "Remarks" column indicates criteria used 
> where the
> > > assignment was not immediately obvious.
> > >
> > > [Rather than repeat the tables, let me summarize by 
> saying that almost
> > > everything goes into Local/Remote.  Here are the 
> exceptional cases:
> > >
> > > Table C.1: Transmission mode (tag 1002) should perhaps be
> > > deprecated beca=
> > > use
> > > the Mode property in LocalControl carries the same
> > > information.  This is
> > > equivalent to saying that the SDP in Local and Remote should
> > > not include =
> > > any
> > > of the directionality attributes.  People may want to comment.
> > >
> > > Table C.1: Gain (tag 100C) and Jitterbuff (tag 100D) are placed in
> > > LocalControl (of local interest only)
> > >
> > > Table C.9: Modem (tag 901B) goes into the Modem Descriptor.
> > > Actually it
> > > should be deprecated because the necessary codepoints have
> > > already been
> > > defined in the Modem descriptor.
> > >
> > > Table C.9: DialledN (tag 901F) and DiallingN (tag 9020) go
> > > into LocalCont=
> > > rol
> > > because they do not require end-to-end coordination at the
> > > media level.]
> > >
> > > Tom Taylor
> > > Multimedia Control and Applications Standards
> > > Ph.  +1 613 736 0961
> > > [email-masked]=20
> > >
>

---

From: Christian Groves <[email-masked]>
Date: Mon, 14 May 2001 04:14:59 +1000

G'Day Tom,

I think we can talk about this in Geneva. I don't want to drop the
"package 0" terminology as its how Annex C is coded. Its a fundamental
part. I'm not sure either that you've identified everything for Local
Control. I'm not in favour of this work as I believe Annex C is a bucket
of information elements much like SDP. Information elements are optional
to implement as they are in SDP. These were fundamental principles when
the 2 encodings were introduced. It should be up to profiles and
documents like Q.1950 to tell you what elements to use in what
situations.

Cheers, Christian

Tom-PT Taylor wrote:
> 
> It looks like I should completely rewrite my contribution to express
> exactly this.  Any other comments?  (Christian may be in the air
> already, in which case I'll talk to him in Geneva next week.)
>