Subject: Re: [AVT] Suggested changes to RFC 2833 re: fax/modem tones

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 04 Nov 2002 13:15:11 -0500

> *Change #1: I have changed the definition of the volume field in Section
> 3.5. You has rightly added Volume? columns to the event tables. However,
> the text in Section 3.5 was wrong in that it said volume was pertinent
> to DTMF only. Volume is important for modem and fax events, and some
> other categories of events. The new text is as follows:
>
> *volume: For DTMF digits and other events representable as tones,
>              this field describes the power level of the tone, expressed
>              in dBm0 after dropping the sign. Power levels range from 0
>              to -63 dBm0. The range of valid DTMF is from 0 to -36 dBm0
>              (must accept); lower than -55 dBm0 must be rejected (TR-
>              TSY-000181, ITU-T Q.24A). Thus, larger values denote lower
>              volume. If this field is not defined for an event,
>
>      it is set to zero by the sender and is
>
>              ignored by the receiver. If a zero volume is indicated for
>                  an event for which the volume field is defined, then
> the receiver
>
>      may reconstruct the volume from interpolation. This allows
>      backwards compatibility with RFC 2833, where the volume field
>     was specified as undefined for non-DTMF events.

I have ad(o|a)pted these changes. Since interpolation didn't seem clear, 
it now says that this refers to surrounding non-event audio. Also, the 
text allows the receiver to pick a default value. I believe that the ITU 
specs for all standardized tones specify such a nominal value. Requiring 
interpolation seems asking a bit much and is probably prone to error.

[More later]

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 04 Nov 2002 13:51:32 -0500

I've incorporated your text on ANS and related tones, with minor tweaks. 
Since I missed the -0x cut-off, a revised version of the I-D won't 
appear until after IETF55, but

http://www.cs.columbia.edu/~hgs/rtp/drafts/draft-ietf-avt-rfc2833bis-02.txt
http://www.cs.columbia.edu/~hgs/rtp/drafts/draft-ietf-avt-rfc2833bis-02.pdf

has a preview.

> These definitions of the ANS, /ANS, ANSam and /ANSam tones refer to the
> entire signal. Unlike ITU Recommendation V.25 [8], they do not refer to
> individual 450 ms cycles.
>
> An ANS or ANSam event packet should not be sent until it is possible to
> discriminate between an ANS and ANSam event. It is however, permissible
> to send an ANS or ANSam event packet before phase reversals can be
> detected. Phase reversals, if any, occur at intervals of 450 +/- 25 ms.
> If a phase reversal is detected after an ANS or ANSam event packet is
> sent, it must be followed by the transmission of an /ANS or /ANSam event
> packet.
>
> *Change #3: I have added a new ANS event, ANS2225. I have done so per an
> action item from ITU SG16 to request you for this event. This event is
> used in equipment for the disabled and it must not be confused with the
> other ANS events. Of course, a new number needs to be allocated to this
> event. I have not done that. The new event is defined as follows:
>
> *        ANS2225: This  2225 Hz answer tone is described in ITU
> Recommendation
>
>     V.18, Annex D for one of several classes of  modems operating in
>          the text telephone mode. It is also referred to in ITU
>      Recommendation  V.22. This is a pure tone with no amplitude
>         modulation and no       semantics attached to phase reversals,
>     if       there are any.
>                                             Event number     Volume????
>
>                 ANS2225                  ??          yes
>
>
> Explanatory note to Henning:   Initially a proprietary "Bell System"
> method, the 2225 Hz answer tone is now included in ITU V.18, Annex D
> which addresses TDD (telecommunications for the disabled) equipment.  It
> is necessary to accommodate it for completeness, and for compliance with
> various legal ordinances. A distinct number must be allocated to this
> event since it must be differentiated from the normal, 2100 Hz ANS when
> reproduced at the far-end gateway.
>
> The following folks have helped me create the suggested changed text:
> Alex Urquizo, Dan Deliberato, Herb Wildfeur and Mehryar Garakani, Bill
> Foster, Flemming Andreasen and Hisham Abdelhamid.
>
> Please comment on these recommended changes.
>
> Thanks,
>
> Rajesh
>

---

From: Gunnar Hellstrom <[email-masked]>
Date: Mon, 4 Nov 2002 23:49:36 +0100

Hi,
I realized that you have soon created a communication method for all signals
discovered by a termination made to report to the MGC according to the call
discrimination and text telephony packages of H.248.

Without detailed comparison, I see that there is one V.8 signal missing. It
is CI, the Call Indicator, carrying the information of the purpose of the
call.
It is essential for V.18, giving an early indication that the call will
contain text telephony.
CI is composed of V.21 signals, but I think it requires its own indication
that a CI has occurred, followed by the parameters.

So, I suggest that CI is included, and a verification is done against the
Text Telephony and Call Type Discrimination packages.

Regards

-------------------------------------------
Gunnar Hellstrom
Omnitor AB
Renathvagen 2
SE 121 37 Johanneshov
SWEDEN
+46 8 556 002 03
Mob: +46 708 204 288
www.omnitor.se
[email-masked]
--------------------------------------------

> -----Ursprungligt meddelande-----
> Fran: [email-masked] [mailto:[email-masked]]For Henning
> Schulzrinne
> Skickat: den 4 november 2002 19:52
> Till: Rajesh Kumar
> Kopia: [email-masked]
> Amne: Re: [AVT] Suggested changes to RFC 2833 re: fax/modem tones
>
>