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

[Henning Schulzrinne <hgs@cs.columbia.edu>]

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