Subject: RE: Annex C Descriptor Assignments

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

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: Troy Cauble <[email-masked]>
Date: Fri, 11 May 2001 10:30:26 -0400

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: