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

From: "Prabhu, Raghavendra" <[email-masked]>
Date: Tue, 29 Oct 2002 11:22:47 -0800

Rajesh and all,

It is not clear to me whether V.25 implies the 2100Hz with phase-reversal to
be {ANS,/ANS,ANS,/ANS ...}  or {ANS,/ANS,/ANS,/ANS...}. The latter might be
more "event friendly". 

On a similar(but maybe different) topic, I guess this discussion implies
that Events (in the interest of being real-time) can be updated in the
future; i.e start off with a guess, and then as time goes on update it as
likelihood increases. We see this scenario when encoding call progress
events  of same frequency but different cadence; have to wait till cadence
to be sure of the event. Does this make any sense ?

Regards,
Raghavendra

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]]
Sent: Saturday, October 26, 2002 2:02 AM
To: Rajesh Kumar
Cc: [email-masked]; [email-masked]; [email-masked]; flemming
Andreasen
Subject: [AVT] Re: Non-standard RFC 2833 definition of ANS, /ANS, ANSam
and /ANSam

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,
> 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
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

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

Prabhu,
I will be providing text to Henning and the AVT for these events today. 
Basically, my suggestion is to KEEP the RFC2833 semantics of ANS,/ANS etc. 
as referring to entire signals rather than to 450 ms phase cycles, as V.25 
does. The only difference is that I'll be adding clarification on how the 
RFC2833 semantics differs, and other explanatory text. So this is a case in 
which we do not want to follow V.25 to the letter in RFC2833.

It does not matter from this perspective which of the two sequences of 
symbols are shown in or implied by V.25. From the RFC2833 events 
perspective, it would make zero sense to send an event message every phase 
cycle. The RFC2833 mechanism of indicating duration, extending duration and 
indicating the end of a tone are more than adequate.

Thanks,

Rajesh