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

Kreuter,
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.

Thanks,

Rajesh

At 03:35 PM 10/30/2002 +0100, Kreuter Ruediger wrote:
>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