Subject: [Megaco] rtp/pl non-double breakage in the V2 IG

From: Troy Cauble <[email-masked]>
Date: Mon, 30 Oct 2006 12:15:35 -0500

I just noticed the following clarification in the
H.248.1 V2 IG involving the rtp/pl value.

It says that rtp/pl is a double that be encoded "x.y"

But if it can be encoded "x.y" it is not a double.
A double is defined in the document as a 64 bit integer.
A double's text encoding is defined as follows.

; Integer, Double, and Unsigned Integer: Decimal values can be encoded
; using characters 0-9. Hexadecimal values must be prefixed with '0x'
; and can use characters 0-9,a-f,A-F. An octal format is not supported.
; Negative integers start with '-' and MUST be Decimal. The SafeChar
; form of VALUE MUST be used.

Saying it can be encoded "x.y" is inventing a new type
that needs to be defined in the main document, with
support for text and ASN.1 encodings.

Casual re-definitions or type inventions within package
definitions should not be allowed.

The problem being solved, a vague original definition,
should be fixed by saying the integer representation is
achieved by multiplying the percentage by 1000.
(Or some other number.)  It could easily be changed
from double to integer as well.

-troy

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: [email-masked]
Date: Tue, 31 Oct 2006 13:17:18 +0100

Troy,
do agree to your analysis, made also a proposal based on "scaling" (see
AVD-2916).
We did discuss this subject already in a couple of meetings (see list
below) this year and finally agreed:

a) to fix the interpretation of rtp/pl in the IMG (i.e., the H.248 served
user instance may only interpret rtp/pl, the H.248 message decoder may not
itself convert it in the final data structure), and
b) extend the set of H.248 data types in H.248.1 Version 4 (i.e. data types
are a V4 living list item).

I would then for H.248.1 V4 propose to use "FLOAT32" (a 4-byte floating
point number according the single-precision 32-bit IEEE 754 format) for
rtp/pl, which would provide the advantages of a native data type, simple
handling of fractional part, and avoidance of "complex data type
conversions".

Regards, Albrecht

1) http://ftp3.itu.int/av-arch/avc-site/2005-2008/0608_Ott/AVD-2916.zip
      Implementers' Guides for H.248.1 Version 2 & 3  ? ABNF Grammar for §
E.12.4.3 Packet Loss rtp/pl

2)
http://www.itu.int/md/meetingdoc.asp?lang=en&parent=T05-SG16-060403-D-0303
      => § 2.6 H.248.1 v1, 2, 3 Clarification on rtp/pl coding

3)
http://www.itu.int/md/meetingdoc.asp?lang=en&parent=T05-SG16-060403-D-0228
      H.248.1 - Discussion on floating numbers data types and example
scenarios for type conversions

4)
http://www.itu.int/md/meetingdoc.asp?lang=en&parent=T05-SG16-060403-D-0227
      H.248.1 - Missing Data Type(s) for Floating Numbers (IEEE 754)

                      Troy Cauble                                                                                                       
                      <troy@bell-labs.         To:      [email-masked]                                                                 
                      com>                     cc:                                                                                      
                                               Subject: [Megaco] rtp/pl non-double breakage in the V2 IG                                
                      30.10.2006 18:15                                                                                                  

-troy

---

From: Troy Cauble <[email-masked]>
Date: Tue, 31 Oct 2006 12:08:59 -0500

Thanks Albrecht,

You concern is more general than mine.

I don't find the arguments for adding FLOATs in V4 compelling.
But if they are to be added, you need to give them real ASN.1
data types.  All of the current parameters have embedded type
information in the ASN.1.  Why should these then be lumped
into OCTET STRING?

But back to my current V1/V2 issue.

What are V1 and V2 compliant systems to do with rtp/pl?
The V2 IG fixed a confusing spec by specifying a *broken syntax*.

If I understand the decision (a) below correctly, it
sidesteps the whole question and doesn't solve anything.
There is no "undefined" parameter type in the protocol.
The way to specify the legal text and ASN.1 encodings
is by picking a type from 12.2.

The only parameter type that can be text encoded "x.y"
is a STRING.  (And it must have the double quotes, btw.)
If we want "x.y", we need to change the type to STRING.

Or we can keep/change/clarify the scaling and either leave
the type as DOUBLE or change it to INTEGER.  (Scaling by
2^8 would fit in an INTEGER and satisfy the precision
specified in RFC3550.)

-troy