AW: [AVT] Re: Non-standard RFC 2833 definition of ANS, /ANS, ANSa m and /ANSam
Kreuter Ruediger <ruediger.kreuter@siemens.com> Wed, 30 October 2002 14:37 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16613 for <avt-archive@odin.ietf.org>; Wed, 30 Oct 2002 09:37:46 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9UEdfW06956 for avt-archive@odin.ietf.org; Wed, 30 Oct 2002 09:39:41 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UEcnv06901; Wed, 30 Oct 2002 09:38:49 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9UEa6v06183 for <avt@optimus.ietf.org>; Wed, 30 Oct 2002 09:36:06 -0500
Received: from gorilla.mchh.siemens.de (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16402 for <avt@ietf.org>; Wed, 30 Oct 2002 09:33:41 -0500 (EST)
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id PAA12537; Wed, 30 Oct 2002 15:35:55 +0100 (MET)
Received: from mchh248e.mchh.siemens.de ([139.21.200.58]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id PAA09636; Wed, 30 Oct 2002 15:35:56 +0100 (MET)
Received: by MCHH248E with Internet Mail Service (5.5.2653.19) id <V6CTPVTQ>; Wed, 30 Oct 2002 15:35:24 +0100
Message-ID: <D17456DF510BD61188E80002A58EDAE9426598@MCHH2A5E>
From: Kreuter Ruediger <ruediger.kreuter@siemens.com>
To: 'Henning Schulzrinne' <hgs@cs.columbia.edu>
Cc: avt@ietf.org, Rajesh Kumar <rkumar@cisco.com>
Subject: AW: [AVT] Re: Non-standard RFC 2833 definition of ANS, /ANS, ANSa m and /ANSam
Date: Wed, 30 Oct 2002 15:35:22 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9UEa7v06184
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
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
- AW: [AVT] Re: Non-standard RFC 2833 definition of… Kreuter Ruediger
- Re: AW: [AVT] Re: Non-standard RFC 2833 definitio… Rajesh Kumar