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

[Kreuter Ruediger <ruediger.kreuter@siemens.com>]

Another question in this context.

If the receiver of these packages is a media gateway,
then my understanding is, that these event packages
should be played out at the TDM side.
Does RFC2833bis allow, that such a packet is also used
to trigger gateway internal configuration actions ?

In this case it would make a big difference if we get
ANS, /ANS, ANS, /ANS, ANS, /ANS, ANS
or 
ANS, /ANS, /ANS, ...

Besides, if this is a valid use of RFC2833 packets,
then this would be a concurrent approach to 
draft-rajeshkumar-mmusic-gpmd-00.txt
for the handling of vbd calls in a VoIP network.

Regards

Rüdiger Kreuter
Siemens AG
ruediger.kreuter@siemens.com

> -----Ursprüngliche Nachricht-----
> Von: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Gesendet: Samstag, 26. Oktober 2002 11:02
> An: Rajesh Kumar
> Cc: avt@ietf.org; bfoster@cisco.com; hisham@cisco.com; flemming
> Andreasen
> Betreff: [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