Subject: RE: [Megaco] rtp/pl *syntax broken* in the V2 IG

From: "Raphael Tryster" <[email-masked]>
Date: Mon, 10 Sep 2007 17:52:58 +0300

To take it a step further, the percentage we are talking about comes from an 8-bit field in the RTCP record, where 00000001 = 0.390625%, 10000000 = 50%, 11111111 = 99.609375%, and so on.  So to convert this number to rtp/pl, multiply by 100/256, and then by 2^32, or more simply, multiply by 100 x 2^24.  Is that correct?

If the 8-bit fraction lost field in RTCP is the only source for this statistic, then the exact numbers Kevin used below would not occur, since 60/256 = 23.4375% and 61/256 = 23.828125%.  Or are you saying, Kevin, that an application may choose different sources for this data, such as dividing the 24-bit cumulative count of packets lost by the number of packets received?  If so, under what circumstances would one data source be preferred over another?

I assume that all this only applies to implementations claiming compliance from a certain version of H.248 or of the rtp package, otherwise supporting the broken syntax using a dot, e.g rtp/pl=23.4375 or rtp/pl="23.4375" has better chances for interoperability.  This is of course a guess, as nobody in the list, myself included, took up Christian's invitation to say how they represented rtp/pl until now.
 
Raphael Tryster

-----Original Message-----
From: Troy Cauble [mailto:[email-masked]] 
Sent: Tuesday, November 28, 2006 6:38 PM
To: Kevin Boyle
Cc: [email-masked]; [email-masked]; Christian Groves
Subject: Re: [Megaco] rtp/pl *syntax broken* in the V2 IG

Kevin,

Sorry for the late response, I was on vacation last week.

The example seems unnecessarily complex.
Aren't your 5 steps equivalent to "multiply the percentage by 2^32"?

(Not multiply the fractional part and combine with the integer part.)

-troy

Kevin Boyle wrote:
> All,
> 
> The IG item in question was modified at the Ottawa Rapporteur's Meeting in August to read like this:
> 
> "Possible values: a 32-bit whole number and a 32-bit fraction. The value shall be encoded in ABNF as a string "x.y" where x is the whole part and y the fractional part of the percentage.
> 
> The actual data type is a fixed point number, which is mapped on the H.248 type "double". The whole number and the fractional part shall be interpreted as 32-bit integer each, thus the "double" type for rtp/pl shall be encoded as the concatenation of two integers. The fractional part must be therefore first converted into an integer, i.e. multiplied by 2^32. 
> 
> Binary encoding shall be as described in clause A.2 for type "integer"."
> 
> It was recognized at the meeting here in Geneva that this text still does not resolve the issue brought up by Troy: that the use of a string breaks the syntax.
> 
> Therefore, I have produced text at the direction of the meeting to address this issue.  I propose the following text:
> 
> "Possible values: a 32-bit whole number and a 32-bit fraction.
> 
> The actual data type is a fixed point number, which is mapped on the H.248 type "double". The whole number and the fractional part shall be interpreted as 32-bit integer each, thus the "double" type for rtp/pl shall be encoded as the concatenation of two integers. The fractional part must be therefore first converted into an integer, i.e. multiplied by 2^32. 
> 
> For example, given the percentage 23.625, to express this in the Packet Loss Statistic we perform the following steps:
> 
> 1. Convert the number to binary: 23.625 base 10 equals 10111.101 base 2.
> 2. Break the binary representation into the whole number and the fraction: Whole = 10111; fraction = .101
> 3. Convert the fraction into a whole number.  Because half of a double is 32 bits wide, multiple the fraction by 232.  The fractional part in our example now becomes 10100000000000000000000000000000.  Note that multiplying a binary number by a power of two is the same as shifting it to the left the same number of places as the power of two by which it is being multiplied.
> 4. Concatenate the whole portion and the converted fraction together: 1011110100000000000000000000000000000 is the binary value of our statistic.
> 5. Convert the binary value to integer: the statistic is reported as having value 101468602368.
> 
> To return the statistic back to its fractional representation, the steps are reversed.  Once the integer is converted back to its binary form, the lower 32 bits represent the fraction and the rest are the whole number.  From there, conversion back to a floating point integer is fairly straightforward.
> 
> Binary encoding shall be as described in clause A.2 for type "integer"."
> 
> Comments? Note that this text will be put forward for approval at the end of the week, therefore any concerns need to be voiced by Thursday.
> 
> Kevin
> (H.248 IG Editor)
> 
> -----Original Message-----
> From: Christian Groves [mailto:[email-masked]] 
> Sent: Wednesday, November 01, 2006 6:27 PM
> To: Troy Cauble
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Megaco] rtp/pl *syntax broken* in the V2 IG
> 
> Hello Troy,
> 
> I'll put this on the agenda of the upcoming q.3/16 meeting.
> I do understand your concerns about redefinition of type. So we can revisit this IG item. Unfortunately it seems given the original definition somebodies implementation is going to be broken no matter what we do. It would be interesting to hear from other on the list as to how they have represented rtp/pl since version one.
> 
> In terms of FLOAT discussion of this has been added to the "H.248.1v4 living list" as it was recognised that any changes for this would result in syntax change.
> 
> Regards, Christian
> 
> Troy Cauble wrote:
> 
>> 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
>>
>>
>> [email-masked] wrote:
>>
>>> 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                                                                                                  
>>>                                                                                                                                         
>>>
>>>
>>>
>>>
>>>
>>> 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
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> Megaco mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/megaco
>>
>>
>>
>>
> 
> 
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco

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

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

---

From: Christian Groves <[email-masked]>
Date: Wed, 12 Sep 2007 12:02:46 +1000

Hello Raphael,

We ended up including an item in the IG and then later in the amendment 
to H.248.1v3. ie.

        E.12.4.3 Packet Loss

*Statistic Name*: Packet Loss

*StatisticID*: pl (0x0006)

*Description*: Describes the current rate of packet loss on an RTP 
stream, as defined in RFC 3550. Packet loss is expressed as percentage 
value: number of packets lost in the interval between two reception 
reports, divided by the number of packets expected during that interval.

*Type*: Double

*Possible values*: a 32-bit whole number and a 32-bit fraction.

The actual data type is a fixed point number, which is mapped on the 
H.248 type “double”. The whole number and the fractional part shall be 
interpreted as 32-bit integer each, thus the “double” type for rtp/pl 
shall be encoded as the concatenation of two integers. The fractional 
part must be therefore first converted into an integer, i.e. multiplied 
by 2^32 .

For example, given the percentage 23.625, to express this in the Packet 
Loss Statistic we perform the following steps:

1. Convert the number to binary: 23.625_10 equals 10111.101_2 .

2. Multiply the binary number by 2^32 . Note that multiplying a binary 
number by a power of two is the same as shifting it to the left the same 
number of places as the power of two by which it is being multiplied. 
1011110100000000000000000000000000000 is the binary value of our statistic.

3. Convert the binary value to a decimal double: the statistic is 
reported as having value 101468602368.

To return the statistic back to its fractional representation, the steps 
are reversed. Once the double is converted back to its binary form, the 
lower 32 bits represent the fraction and the rest are the whole number. 
 From there, conversion back to a floating point number is fairly 
straightforward.

Binary encoding shall be as described in clause A.2 for type “integer”.

*Level*: Either

Regards, Christian