Subject: Relationship Annex C values <=> package Property ID's

From: "Bemmel, Jeroen van (Jeroen)" <[email-masked]>
Date: Thu, 3 May 2001 12:01:06 +0200

Hello all,
 
The relationship between value tags in Annex C and attribute identifiers in
packages is unclear and confusing to me:
 
For instance, Annex C defines PropertyID Jitterbuff = 100D, an unsigned
integer 0-65535 representing time in ms
Networkpackage defines Property ID jit = 0x0007 as an attribute to the
LocalControlDescriptor
 
1) Am I correct in assuming that the Annex C value is meant to be assigned
to LocalControlDescriptor.JitterBuffer ?
 
2) If so, how come some of the other Annex C Property IDs are not defined as
attributes anywhere?
 
3) And, if these attributes are not defined, then where is the MG supposed
to keep state information to report when receiving an audit request
    for all terminations (eg step 19 in Appendix A - Example call flows,
resulting in a report of the RTP IP address (amongst others)) ?

Jeroen van Bemmel
Developer New Technologies

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 3 May 2001 10:16:15 -0400

I have never fully understood the use of Annex C, so I can't give the
authoritative word on how it works.  Perhaps we need a discussion to clarify
the matter.

Here is my view of the nature of Annex C:

1) Annex C consists of properties which belong in various descriptors.  An
open action item is to specify the appropriate descriptor for each property.

2) Annex C is technically "package 0", which is available only for binary
encoding.  It represents relatively early thinking in the development of the
protocol.  To the extent to which it can be superseded by other packages, it
should be, both because the other packages group properties, signals, etc.
which should be implemented together and because the other packages provide
both text and binary encoding in the same place.

3) A considerable part of Annex C is devoted to bearer-related properties,
which belong in the Local and Remote descriptors.  (This statement is
subject to debate, but it can be justified on the grounds that it provides a
better fit with SIP than putting the properties into LocalControl.)  To
provide text-encoded equivalents, these properties have to be added to SDP.
Hence the importance in my mind of the ATM and TDM SDP extensions.

4) One of the thrusts behind Annex C was the concept of "native encoding".
This means that the values following the tags are allowed to be lifted from
a variety of other protocols.  I was startled the other day to learn that
you could ship PER-encoded H.245 inside Megaco/H.248, but I can't contradict
that notion: Annex C simply doesn't provide enough detail to accept or
reject it.  I will point out that there is a certain amount of modification
of Q.931-related values in Annex C, as an example, because the individual
values are unpacked from the octets within which Q.931 encodes them and
shifted to align with the octet boundary.  I see this as inconsistent with
simply taking globs of H.245 "as is" and shipping them to the other end, but
anything is possible with prior agreement.

5) I was never clear on what should follow the SDP-related tags.  To be
consistent with the H.245 approach, I suppose what would follow would be the
actual SDP text strings, but I don't know.

In conclusion: I think we need a clearer view of how Annex C is to be used
in general, we need to replace at least some of the Annex with properties
defined in other packages, and we need to specify which descriptors the
remaining properties should go in.

> -----Original Message-----
> From: Bemmel, Jeroen van (Jeroen) [mailto:[email-masked]]
> Sent: Thursday, May 03, 2001 6:01 AM
> To: [email-masked]'
> Subject: Relationship Annex C values <=> package Property ID's
> 
> 
> Hello all,
>

---

From: "Bemmel, Jeroen van (Jeroen)" <[email-masked]>
Date: Thu, 3 May 2001 16:43:43 +0200

That still leaves the question about where the state information should go,
regardless of the type of encoding used
 
I noticed that none of the packages defined so far defines any attributes
for local or remote. However, does this mean it is not allowed?

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 7 May 2001 13:08:17 -0400

One way or another, we have an open issue here.  On the basis of your
position, we have to identify which descriptor(s) each element of Annex C
can appear in.  I will volunteer to create a contribution for the SG 16
meeting, to be added to the Implementor's Guide, unless someone else wants
to do it.

> From: Christian Groves [mailto:[email-masked]]
> Sent: Friday, May 04, 2001 12:20 AM
> To: Troy Cauble
> Cc: Terry L Anderson; Rosen, Brian; Taylor, Tom-PT [NORSE:B881:EXCH];
> 'Bemmel, Jeroen van (Jeroen)'; [email-masked]'
> Subject: Re: Relationship Annex C values <=> package Property ID's
> 
> 
> Annex C can be extended by people making contributions and adding new
> parameters. New versions of Annex C can be worked upon if people want
> new information elements. 
> 
> I'd prefer not to revisit a discussions that we had 1999 on the use of
> native tags, SDP etc. We chose to have 2 different schemes. Being 2
> different encodings schemes there will always be differences 
> as SDP has
> a life of its own as well as Annex C. Both SDP and Annex C are buckets
> for information elements. You pick and choose to use the ones 
> you want.
> 
> Technically a package could extend annex C because all 
> properties in the
> binary version of H.248 take the form of 
> package:property=value. Annex C
> is package 0. Termination State, Local Control, Local and Remote all
> have this encoding in the binary version. Which I think is 
> rather handy. 
> 
> I never did see why in the text encoding why local control, 
> termination
> state, local and remote must be coded differently. We have 
> what we have.
> 
> Christian
> 
> Troy Cauble wrote:
> > 
> > Terry L Anderson wrote:
> > >
> > > Troy Cauble wrote:
> > >
> > > >
> > > > Section C.11 is a line by line SDP replacement.  Some 
> of the other
> > > > Annex C
> > > > items seem to be alternative encodings of information 
> that could be
> > > > encoded
> > > > as SDP.
> > > >
> > > > IMHO, if any Annex C items don't have corresponding SDP 
> elements, they
> > > >
> > > > should be removed.  It is fundamentally wrong to have 
> features that
> > > > are only
> > > > accessible to the ASN.1 encoding of the protocol.  We should be
> > > > striving
> > > > for uniformity.
> > >
> > > They should agree, but this can be fixed as you suggest 
> (remove Annex C
> > > item) or by ADDing SDP.  Many can be added through 'a=' 
> attributes in
> > > SDP and RFCs can add these as was suggested in
> > > draft-ietf-mmusics-sdp-atm-05 or recent 
> draft-taylor-mmusic-sdptdm-00
> > > do.  Many of these in Annex C and not yet in SDP are vital for
> > > configuring specific termination types.  These could be 
> added through
> > > packages to LocalControl but this makes it more difficult 
> for them to be
> > > media specific.  SDP allows the parameter to apply to 
> only specific
> > > choices of the multiple proposed media.
> > >
> > > Removing them would seriously affect backward compatibility and so
> > > probably not possible.
> > 
> > I had forgotten that the things in the Local and Remote Descriptors
> > are not Properties.  Packages won't work here.
> > 
> > So for LD & RD non-properties in Annex C that are not yet in SDP,
> > people will have a choice between using ASN.1 encoding only or
> > influencing the evolution of SDP.
> > 
> > Consider the reverse direction.  How will new items that come out
> > of the evolution of SDP make it into Annex C for ASN.1 encoding?
> > Do we need a formal mechanism (like Packages) to extend Annex C?
> > 
> > On the other hand, the IG ammended the intro to Annex C to
> > say that (some of?) the Annex C non-properties apply to the
> > LocalControlDescriptor.  (But nothing tells us which ones.)
> > 
> > I would argue that any Annex C items that apply to the LCD
> > *ARE* Properties, and should be removed from Annex C and moved
> > to Packages.  Otherwise how will they be encoded as text?
> > 
> > -troy
> > 
> > > >
> > > >
> > > > People who need the non-SDP supported features 
> currently in Annex C
> > > > should be developing Packages, rather than going with 
> an ASN.1 only
> > > > solution.
> > > >
> > > > Can we seek out  and remove non-SDP supported features 
> in Annex C?
> > > >
> > > > -troy
> > > >
> > > >
>