Subject: [AVT] Non-standard RFC 2833 definition of ANS, /ANS, ANSam and /ANSam

From: Rajesh Kumar <[email-masked]>
Date: Thu, 24 Oct 2002 15:46:00 -0700

Henning,
There are certain issues with the definition of the ANS, /ANS, ANSam and 
/ANSam events that need clarification.

Since at least 450 ms is needed to detect a phase reversal, it is not 
possible to discriminate between ANS and /ANS before 450 ms. However, this 
results in an unacceptable delay in informing the far end that a 2100 Hz 
signal (whatever its variant) has been detected. It takes less than 200 ms 
to detect that fact that this is a 2100 Hz signal.

Question 1: Does RFC 2833 consider it acceptable to send an ANS event (200 
ms) and then an /ANS event (450 ms), thereby using the /ANS event as an 
"update" of the ANS event? The same consideration would apply to ANSam and 
/ANSam.  This would change how you have defined these events in RFC 2833.

Queston 2: Your use of the "bar" or "slash" is at odds with that of the ITU 
V.25. In the ITU specification, /ANS is not a separate signal but refers to 
the 2100 Hz cycle during which phase is reversed. Thus, the RFC 2833 
definition of /ANS corresponds to the following ITU V.25 sequence, where 
each element in the sequence is one cycle:
	ANS, /ANS, ANS, /ANS, ANS, /ANS, ANS

However,  I have no problem with your re-definition of that the "bar" or 
"slash" means. I only want to point out that you say in RFC 2833 that your 
definition is equivalent to the ITU's, when it isn't. Please look at Figure 
3 of ITU V.25 and add the applicable clarification in your document.

Thanks,

Rajesh 

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 26 Oct 2002 05:02:07 -0400

I've been relying on the expertise of others in describing these. I 
would thus value a more concise and V.25-compliant definition of these 
events. Can you provide text?

Rajesh Kumar wrote:
> possible to discriminate between ANS and /ANS before 450 ms. However, 
> this results in an unacceptable delay in informing the far end that a 
> 2100 Hz signal (whatever its variant) has been detected. It takes less 
> than 200 ms to detect that fact that this is a 2100 Hz signal.
> 
> Question 1: Does RFC 2833 consider it acceptable to send an ANS event 
> (200 ms) and then an /ANS event (450 ms), thereby using the /ANS event 
> as an "update" of the ANS event? The same consideration would apply to 
> ANSam and /ANSam.  This would change how you have defined these events 
> in RFC 2833.
> 
> Queston 2: Your use of the "bar" or "slash" is at odds with that of the 
> ITU V.25. In the ITU specification, /ANS is not a separate signal but 
> refers to the 2100 Hz cycle during which phase is reversed. Thus, the 
> RFC 2833 definition of /ANS corresponds to the following ITU V.25 
> sequence, where each element in the sequence is one cycle:
> "slash" means. I only want to point out that you say in RFC 2833 that 
> your definition is equivalent to the ITU's, when it isn't. Please look 
> at Figure 3 of ITU V.25 and add the applicable clarification in your 
> document.
> 
> Thanks,
> 
> Rajesh

---

From: Rajesh Kumar <[email-masked]>
Date: Sun, 27 Oct 2002 18:00:20 -0700

OK

At 05:02 AM 10/26/2002 -0400, Henning Schulzrinne wrote:
>I've been relying on the expertise of others in describing these. I would 
>thus value a more concise and V.25-compliant definition of these events. 
>Can you provide text?
>
>Rajesh Kumar wrote:
>>Henning,
>>(200 ms) and then an /ANS event (450 ms), thereby using the /ANS event as 
>>an "update" of the ANS event? The same consideration would apply to ANSam 
>>and /ANSam.  This would change how you have defined these events in RFC 2833.
>>refers to the 2100 Hz cycle during which phase is reversed. Thus, the RFC 
>>2833 definition of /ANS corresponds to the following ITU V.25 sequence, 
>>where each element in the sequence is one cycle:
>>your definition is equivalent to the ITU's, when it isn't. Please look at 
>>Figure 3 of ITU V.25 and add the applicable clarification in your document.
>>Thanks,
>>Rajesh
>

---

From: Rajesh Kumar <[email-masked]>
Date: Wed, 30 Oct 2002 14:08:30 -0800

Henning,
I have sent you an email a few minutes back with an RFC2833bis enclosure, 
and the suggested changes marked. In the present email, I am listing points 
from that enclosure for review by the AVT group. The requested changes are:

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.

Change #2: I have re-done the definitions of ANS, /ANS, ANSam and /ANSam to 
indicate that these definitions follow semantics that are different from 
V.25 semantics, and for a good reason. I have also added precautions that 
must be followed when  detecting and reporting these events. The new 
definitions are as follows:

                 ANS:  <<<---definition unchanged----------->>>

         /ANS: This is the same signal as ANS, except that it reverses
              phase at an interval of 450 +/- 25 ms. It disables both
                echo cancellers and echo suppressors. (In the ITU
              Recommendation V.25 [8],  an ANS with a bar on top refers
              to individual phase-reversed cycles rather than to the
                entire signal.)

         ANSam: <<<---definition unchanged----------->>>

         /ANSam: <<<---definition unchanged----------->>>

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