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

["Prabhu, Raghavendra" <Raghavendra.Prabhu@intel.com>]

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:hgs@cs.columbia.edu]
Sent: Saturday, October 26, 2002 2:02 AM
To: Rajesh Kumar
Cc: avt@ietf.org; bfoster@cisco.com; hisham@cisco.com; 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
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt