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