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
>