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

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 3 May 2001 10:31:46 -0400

Wow, shows just how out of sync we all are -- Tom and I usually have the
same view of these kinds of things.
 
I thought Annex C is ONLY used in remote and local when binary encoding.
It replaces SDP.  When you text encode, you use SDP in remote and local,
when you binary encode you use Annex C in Remote and Local
 
It's not a "package" because you don't use any of the Annex C tags in
LocalControl
or TerminationState, and you don't ever use any other package defined
elements
in local and remote.  There was a certain amount of effort put into making
sure
whatever you could say in SDP, there was an equivalent in Annex C.
 
Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Thursday, May 03, 2001 10:16 AM
To: 'Bemmel, Jeroen van (Jeroen)'; [email-masked]'
Subject: RE: Relationship Annex C values <=> package Property ID's

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]
<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, 
>  
> 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: Troy Cauble <[email-masked]>
Date: Thu, 03 May 2001 11:15:21 -0400

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.

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

"Rosen, Brian" wrote:

>  Wow, shows just how out of sync we all are -- Tom and I usually have thesame
> view of these kinds of things.I thought Annex C is ONLY used in remote and
> local when binary encoding.It replaces SDP.  When you text encode, you use
> SDP in remote and local,when you binary encode you use Annex C in Remote and
> LocalIt's not a "package" because you don't use any of the Annex C tags in
> LocalControlor TerminationState, and you don't ever use any other package
> defined elementsin local and remote.  There was a certain amount of effort
> put into making surewhatever you could say in SDP, there was an equivalent in
> Annex C.Brian
>
>      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.
>
>      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.
>
>      > From: Bemmel, Jeroen van (Jeroen) [mailto:[email-masked]]

---

From: Terry L Anderson <[email-masked]>
Date: Thu, 03 May 2001 14:54:17 -0400

> accessible to the ASN.1 encoding of the protocol.  We should be

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.

>> Wow, shows just how out of sync we all are -- Tom and I usually have
>> thesame view of these kinds of things.I thought Annex C is ONLY used
>> in remote and local when binary encoding.It replaces SDP.  When you
>> text encode, you use SDP in remote and local,when you binary encode
>> you use Annex C in Remote and LocalIt's not a "package" because you
>> don't use any of the Annex C tags in LocalControlor
>> TerminationState, and you don't ever use any other package defined
>> elementsin local and remote.  There was a certain amount of effort
>> put into making surewhatever you could say in SDP, there was an
>> equivalent in Annex C.Brian
>>
>>      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.
>>
>>      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
--
------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:908.582.7013   Fax:908.582.6729
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

---

From: "Madhu Babu Brahmanapally" <[email-masked]>
Date: Thu, 3 May 2001 15:09:30 -0400

Its true that the Annex C lists many properties that are not there in SDP.
Apart from that there are properties like JitterBuffer (As pointed by
Bemmel), Echo Cancellation, Gain Control which are present both as
properties of package and in Annex C. If say, JitterBuffer property appears
both in Local Control Descriptor (PACKAGE DEFINED) and in local descriptor
(ANNEX C), then the one specified in the Local descriptor should be
discarded. The same was the case with mode parameter which can appear both
in the local control descriptor and SDP. A statement can be added in the IG
to mention that if the properties appears twice (I'm not sure whether Error
code "456 - Parameter or Property appears twice in this Descriptor" is valid
here) , then the local control descriptor defined once takes the precedence.

Regards
Madhubabu
  -----Original Message-----
  From: [email-masked]
[mailto:[email-masked]]On Behalf Of Troy Cauble
  Sent: Thursday, May 03, 2001 11:15 AM
  To: Rosen, Brian
  Cc: 'Tom-PT Taylor'; 'Bemmel, Jeroen van (Jeroen)'; [email-masked]'
  Subject: Re: Relationship Annex C values <=> package Property ID's

  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.

  -troy

  "Rosen, Brian" wrote:

     Wow, shows just how out of sync we all are -- Tom and I usually have
thesame view of these kinds of things.I thought Annex C is ONLY used in
remote and local when binary encoding.It replaces SDP.  When you text
encode, you use SDP in remote and local,when you binary encode you use Annex
C in Remote and LocalIt's not a "package" because you don't use any of the
Annex C tags in LocalControlor TerminationState, and you don't ever use any
other package defined elementsin local and remote.  There was a certain
amount of effort put into making surewhatever you could say in SDP, there
was an equivalent in Annex C.Brian
      -----Original Message-----
      From: Tom-PT Taylor [mailto:[email-masked]]
      Sent: Thursday, May 03, 2001 10:16 AM
      To: 'Bemmel, Jeroen van (Jeroen)'; [email-masked]'
      Subject: RE: Relationship Annex C values <=> package Property ID's

      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.

---

From: Troy Cauble <[email-masked]>
Date: Thu, 03 May 2001 15:32:24 -0400

> Removing them would seriously affect backward compatibility and so

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

---

From: Christian Groves <[email-masked]>
Date: Fri, 04 May 2001 14:20:24 +1000

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