Subject: [Megaco] Floating point numbers

From: Christian Groves <[email-masked]>
Date: Tue, 14 Aug 2007 12:48:29 +1000

Hello all,

At the last Q.3/16 meeting we reviewed a contribution proposing to add 
floating point number support to H.248.1v4. However we could not come to 
agreement on the format of the floating point number to be used in the 
text encoding of the protocol. Basically there are two options: 1. Make 
it machine friendly or 2. Make it person friendly. This is described in 
the email below. The issue is also described in the H.248.1v4 Living 
list. It should appear shortly in: 
http://ftp3.itu.int/av-arch/avc-site/2005-2008/0706_Gen/H248_1v4_Living_List.zip

Encoding is close to the heart of a few people on the list, opinions on 
which option people would prefer?

Regards, Christian

-------- Original Message --------
Subject: 	RE: floating point numbers;RE: H.248.1v4 Living List
Date: 	Wed, 4 Jul 2007 17:55:24 +0100
From: 	Elad Chomsky <[email-masked]>
To: 	Schwarz Albrecht <[email-masked]>, Christian 
Groves <[email-masked]>

Hi Albrecht,

If I understand you correctly, at the highest level we have two options
for text-encoding floats:

1/ Use OctetString to directly represent the number in the IEEE 754
format.
This encoding is fast, compact and accurate. However it is not very
readable.

2/ Encode the floating-point number in a readable fashion. This encoding
is slower and less compact.

If we go with option (2), we have further two sub-options:

2.a/ Encode the number using the standard decimal representation (e.g.
+3.739E-19 - similar to the output of the %E printf flag).
This encoding is the most common one (for example, in the RFC reference
you provided). However it is the slowest and least compact. It also
enables encoding values with no equivalent IEEE 754 float (e.g. 0.1).

2.b/ Encode the number using some readable representation, more aligned
with the binary nature of IEEE 754. My mapping suggestion was such a
representation (though, in retrospect, not a very good one).

Thinking about it now, it seems that (2.b) is probably not that more
readable than (1). So we should probably choose between (1) and (2.a)
only.

Thanks,
Elad

-----Original Message-----
From: Schwarz Albrecht [mailto:[email-masked]] 
Sent: Wednesday, July 04, 2007 6:49 PM
To: Elad Chomsky; Christian Groves
Subject: RE: floating point numbers;RE: H.248.1v4 Living List

Hi Elad,

try to summarize:

The two new proposed H.248 data types should be encoded according IEEE
754, i.e. as 32 or 64 bit values respectively. Right? Because the whole
idea is 
a) to minimize conversion effort between other instances (e.g. served
application of H.248) using that values,
and
b) to avoid loss of accuracy (due to different float formats, or a
conversion between float and fix-frac)
apart from
c) the requirement for a native data type for application requiring
floating-point numbers.

Now, I may agree that the textual representation must not be identical
to the machine format, thus I may follow your "mapping" concept. Guess
that you are using at least two mapping aspects:

1) denormalization
2) decimal representation of <frac> and <exp>
another one might be:
3) basis 10 instead 2
 
May you agree, or do you want to consider e.g. also a decimal-based
encoding of <frac> and/or <exp>?

Regards,
Albrecht

PS
Concerning protocol syntax for H.248 text encoding, we may use this
reference:
Appendix B/RFC 3780 provides ABNF grammar rules for IEEE 754 floating
numbers
See also D-227.

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

---

From: <[email-masked]>
Date: Tue, 14 Aug 2007 17:29:48 +0800

Hello all,

For ASN.1 binary-encoding H.248.1(09/2005), there is recursive type definition for RegulatedEmbeddedDescriptor.

See below:

RegulatedEmbeddedDescriptor ::= SEQUENCE

{

     secondEvent            SecondEventsDescriptor OPTIONAL,   -- look this field

     signalsDescriptor      SignalsDescriptor OPTIONAL,

     ...

}

SecondEventsDescriptor ::= SEQUENCE

{

     requestID              RequestID OPTIONAL,

     eventList              SEQUENCE OF SecondRequestedEvent,   -- look this field

     ...

}

SecondRequestedEvent   ::= SEQUENCE

{

     pkgdName               PkgdName,

     streamID               StreamID OPTIONAL,

     eventAction             SecondRequestedActions OPTIONAL,   -- look this field

     evParList              SEQUENCE OF EventParameter,

     ...

}

}

SecondRequestedActions ::= SEQUENCE

{

     keepActive             BOOLEAN OPTIONAL,

     eventDM                EventDM OPTIONAL,

     signalsDescriptor      SignalsDescriptor OPTIONAL,

     ...,

     notifyBehaviour        NotifyBehaviour OPTIONAL,              -- look this field

     resetEventsDescriptor  NULL OPTIONAL

}

NotifyBehaviour        ::= CHOICE

{

     notifyImmediate        NULL,

     notifyRegulated        RegulatedEmbeddedDescriptor,          -- look this field

     neverNotify            NULL,

     ...

}

RegulatedEmbeddedDescriptor ::= SEQUENCE

{

     secondEvent                SecondEventsDescriptor OPTIONAL,      -- look this field, Recursive type definition:

     signalsDescriptor      SignalsDescriptor OPTIONAL,

     ...

}

Is such definition correct? 

Thank you for any help.

Haiyan