Subject: [Megaco] Gain in TDM package and in Annex C

From: Terry L Anderson <[email-masked]>
Date: Thu, 01 Aug 2002 12:24:10 -0400

There have been several issues raised over the last month or so about 
gain in the TDM package (Annex E.13) as well as in Annex C.  I will 
summarize the issues and propose changes to address them.

1. tdmc/gain is defined as integer which in 12.1.2 is clearly signed but 
the description and choice of value for "automatic" seem to have assumed 
that the value was unsigned.  [concensus was that gain should be signed, 
negative values have useful meaning and that the reserved value for 
automatic should be changed.  Note this last issue is definitely not 
backward compatible but no objections were raised.]

2. tdmc/gain does not specify if it applies to outbound signal level, 
inbound or both. [concensus was that it should be for outbound signal 
level.]

3. Nigel Williams suggested that the value in text encoding be 
restricted to decimal (non-hex) representation for easier parsing. 
[there was no discussion on this, but since the comment the in B.2 
specifies that either decimal and hexadecimal can be used for positive 
values of any integer property, I think we should NOT make this a 
special case.  Note that the specification does require decimal for 
negative values.]

4. There is also a Gain in C.1 (100C) for binary encoding.  It is not 
clear what it applies to and it is defined as unsigned integer and 
0..65535 (evidently 2 bytes). [Concensus was that this should be 
deprecated similar to what we did for echo control.]

I propose the following changes:

C.1
Gain, Property Tag 100C:  Remove the Type entry and change the Value 
entry to:
    Not used.  See H.248.1 Annex E.13 for an alternative gain property.

Annex E.13.1 Gain Control
Description:
Currently:
Gain control, or usage of of signal level adaptation and noise level 
reduction is used to adapt the level of the OUTBOUND signal. However, it 
is necessary, for example for modem calls, to turn off this function. 
[uppercase used only to indicate the addition.  It would be added as 
lowercase.]

Possible Values:

Currently:
    The gain control parameter may either be specified as "automatic" 
(0xffffffff), or as an explicit number of decibels of gain (any other 
integer value).  The default is provisioned in the MG.

Change to:
    The gain control parameter specifies the gain in decibels (positive 
or negative).  Values can range from - 2147483648 to 2147483646 
(0x7ffffffe) with the maximum positive value, 214748646 (0x7fffffff), 
reserved to represent "automatic".  The default value is provisioned in 
the MG.

[Note I am suggesting 0x7fffffff as the new reserved value, even though 
that makes the range more asymmetric, rather than 0x80000000 because 
that is a negative number and the note at the beginning of B.2 would 
require that it be represented in decimal, while I believe that some 
might prefer the easier to remember hex value for this.  I don't believe 
that the asymmetry is an issue, since the large values are useless in 
practice. Also this makes it differ in only one bit from the previous 
reserved value.]

-- 

------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:732.949.5628   Fax:732.949.7016
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2G-219A, 101 Crawfords Corner Rd, Holmdel, NJ 07733-3030
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

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

---

From: Christian Groves <[email-masked]>
Date: Fri, 02 Aug 2002 11:59:13 +1000

G'Day Terry,

I support the changes but if we are assigning values to gain perhaps we should
modify the range to be something more appropriate. -2147483648 to 2147483646
decibels is probably a bit large, I doubt even if you detonate a nuke in your
media gateway you'd get something that loud. Perhaps something like -100 to 100
decibels is more appropriate?

Cheers, Christian

---

From: Christian Groves <[email-masked]>
Date: Fri, 02 Aug 2002 11:59:13 +1000

G'Day Terry,

Cheers, Christian

---

From: Aleksandr Ryabin <[email-masked]>
Date: Fri, 02 Aug 2002 09:53:32 -0400

Hi,

         I don't see any reason at all why a range should be specified.
All what really is required to be corrected is to state that it is a signed 
value
and some other value is reserved for "automatic" (e.g 214748646 (0x7fffffff)).

So if we strike the following words from proposed change it will be exactly
what needed to be changed:

"Values can range from - 2147483648 to 2147483646
(0x7ffffffe) with the maximum positive value,"

Thanks
         Aleks

---

From: Aleksandr Ryabin <[email-masked]>
Date: Fri, 02 Aug 2002 09:53:32 -0400

Hi,

Thanks
         Aleks

---

From: Terry L Anderson <[email-masked]>
Date: Fri, 02 Aug 2002 10:37:05 -0400

We have no type equivalent to a short or 2-byte unsigned integer but I 
take it you support limitting the range using the Possible Values 
section to something more rational, while keeping the type as 4-byte 
unsigned integer.  This saves nothing in the message, but would suggest 
implementors need not attempt support for irrationally large values. 
 Any objections?  I would assume that 100 db in either direction is 
adequate.  "automatic" could stay as proposed (0x7ffffffff) or change to 
something just outside the new limitted range (101 or 0xff=255). What 
would we prefer?

--

---

From: Terry L Anderson <[email-masked]>
Date: Fri, 02 Aug 2002 10:37:05 -0400

--

---

From: Christian Groves <[email-masked]>
Date: Mon, 05 Aug 2002 13:25:40 +1000

G'Day Terry,

I'm not advocating to change the type (to short etc) so this will not change the
encoding or syntax. I'm happy for automatic to stay as proposed.

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Mon, 05 Aug 2002 13:25:40 +1000

G'Day Terry,

Regards, Christian