RE: DTMF timing (was Re: [Sip] INFO ...)

Hadriel Kaplan <HKaplan@acmepacket.com> Thu, 01 November 2007 22:15 UTC

Return-path: <sip-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IniJq-0006Av-T8; Thu, 01 Nov 2007 18:15:18 -0400
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1IniJo-00067k-V1 for sip-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 18:15:16 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IniJo-00063j-JD for sip@ietf.org; Thu, 01 Nov 2007 18:15:16 -0400
Received: from host6.216.41.24.conversent.net ([216.41.24.6] helo=etmail.acmepacket.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IniJj-0000pN-4f for sip@ietf.org; Thu, 01 Nov 2007 18:15:11 -0400
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.0.744.0; Thu, 1 Nov 2007 18:15:10 -0400
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 1 Nov 2007 18:15:10 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Dean Willis <dean.willis@softarmor.com>, Michael Procter <michael.procter@citel.com>
Date: Thu, 01 Nov 2007 18:15:07 -0400
Subject: RE: DTMF timing (was Re: [Sip] INFO ...)
Thread-Topic: DTMF timing (was Re: [Sip] INFO ...)
Thread-Index: AcgczZpKg16KWcQMSX65Iplw2Bm2XwABIPmw
Message-ID: <E6C2E8958BA59A4FB960963D475F7AC3022B427008@mail.acmepacket.com>
References: <8983EC086A9D954BA74D9763E853CF3E04183D84@xmb-rtp-215.amer.cisco.com> <63DAB754-7CAF-48DA-9E47-96905FE45E81@nostrum.com> <9EE99659-BC47-4F29-8C95-652A95D2EF7B@softarmor.com> <EFC02CB0-F640-49D1-8C51-349A909DC9D0@nostrum.com> <20C2BE8C-BBBF-474F-967D-81438FF4EDF0@softarmor.com> <472505F8.5090401@nostrum.com> <8FF0EFA1-77DA-4D68-9B34-2AB904C9ED42@softarmor.com> <47255D1A.30206@nostrum.com> <E6C2E8958BA59A4FB960963D475F7AC3022B33C132@mail.acmepacket.com> <472756C2.1010205@nostrum.com> <47277440.3050707@cisco.com> <E6C2E8958BA59A4FB960963D475F7AC3022B33C881@mail.acmepacket.com> <0D5F89FAC29E2C41B98A6A762007F5D037DBFB@GBNTHT12009MSX.gb002.siemens.net> <6A5ECF04-A5D5-494A-8542-79993361AC05@softarmor.com> <006d01c81cb1$0ba65b60$22f31220$@com> <0D4E483A0E6E0A46861409E5D6C2011C0E5A3D@sea02-mxc01.citel.com> <1C0CC329-89F4-4A07-A163-8C893A329E96@softarmor.com>
In-Reply-To: <1C0CC329-89F4-4A07-A163-8C893A329E96@softarmor.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Cc: "sip@ietf.org" <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Errors-To: sip-bounces@ietf.org


> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.com]
>
> On Nov 1, 2007, at 3:20 PM, Michael Procter wrote:
>
> > Whilst having the RFC2833 arriving in the timestamped audio stream
> > is certainly beneficial, it is also true to say that the RTP stream
> > generally travels quicker than signalling.  One of the main reasons
> > for this is that the RTP usually travels point-to-point, whilst the
> > signalling path often includes a couple of proxies.  Even if the
> > proxies process the messages in zero time (which they don't), there
> > are still multiple network hops introduced as a consequence.
> > Additional delays incurred by the proxies/other intermediate
> > signalling elements swiftly add up too.
>
> I agree that this sounds correct in theory.
>
> What I'm wondering about is those deployments that use media-path
> control elements (aka SBCs that police media) and/or decoupled media
> and signaling processors.
>
> I suspect that that SBCs slow down RTP about as much as they slow
> down SIP. COuld be more, could be less -- I don't really know.

Uh, nope.  There are such things as software-based SBCs, for enterprises and such, but most of the provider ones use dedicated hardware to handle RTP/RTCP. (using NPs/ASICS/whatever)  It's not discernibly slower than a router, depending on the vendor.


> We don't really use DTMF much between "traditional SIP endpoints" --
> the kind of all-in-one device that does everything in a dedicated
> general-purpose processor. It seems that in practice we use it more
> frequently in transactions that involve large-scale decoupled
> gateways and decoupled media servers, at least at one end of the
> call. I wouldn't be surprised to see the practical reality collide
> with the theory around 2833.

Yeah, I buy that.
My worry though isn't about speed.  It's about use.  One of the obvious use cases for signaling-based DTMF is it follows the signaling, and the media doesn't need to.  For an info-dtmf model, that essentially means something in the middle that wants dtmf (an app-server, for example) has to act as a b2bua for signaling, but doesn't need to be in the media path.  So even if both info-dtmf and 2833 get negotiated, you'd want to use the info-dtmf.  Although I guess if the app-server needed it that way, it would have to have removed 2833 from SDP (yuck), 'cause otherwise as a UA it's essentially lying by offering 2833.

-hadriel



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip