RE: DTMF timing (was Re: [Sip] INFO ...)
"Eric Burger" <eburger@bea.com> Sun, 04 November 2007 17:17 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 1Ioj6I-00022V-3U; Sun, 04 Nov 2007 12:17:30 -0500
Received: from sip by megatron.ietf.org with local (Exim 4.43) id 1Ioj6G-00020k-Q4 for sip-confirm+ok@megatron.ietf.org; Sun, 04 Nov 2007 12:17:28 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ioj6G-0001zv-Df for sip@ietf.org; Sun, 04 Nov 2007 12:17:28 -0500
Received: from repmmg02.bea.com ([66.248.192.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ioj6F-0006Pr-Nr for sip@ietf.org; Sun, 04 Nov 2007 12:17:28 -0500
Received: from repmmr02.bea.com (repmmr02.bea.com [10.160.30.72]) by repmmg02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lA4HHQkE003614; Sun, 4 Nov 2007 09:17:26 -0800
Received: from repbex01.amer.bea.com (repbex01.bea.com [10.160.26.98]) by repmmr02.bea.com (Switch-3.3.0/Switch-3.2.7) with ESMTP id lA4HHO9R003336; Sun, 4 Nov 2007 09:17:24 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: RE: DTMF timing (was Re: [Sip] INFO ...)
Date: Sun, 04 Nov 2007 09:17:19 -0800
Message-ID: <A5E9CBACB726CB4BAA3DAFF0925C188F0215F2BF@repbex01.amer.bea.com>
In-Reply-To: <E6C2E8958BA59A4FB960963D475F7AC3022B427008@mail.acmepacket.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: DTMF timing (was Re: [Sip] INFO ...)
Thread-Index: AcgczZpKg16KWcQMSX65Iplw2Bm2XwABIPmwAIzYJGA=
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> <E6C2E8958BA59A4FB960963D475F7AC3022B427008@mail.acmepacket.com>
From: Eric Burger <eburger@bea.com>
To: Dean Willis <dean.willis@softarmor.com>
x-BEA-PMX-Instructions: AV
x-BEA-MM: Internal-To-External
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6
Cc: 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
Review KPML and the Application Interaction Framework. RTP (RFC 4733/2833) is for the *timely*, _unreliable_, delivery of TONES. SIP (RFC 4730) is for the _reliable_, *soon-enough*, delivery of SIGNALING. Please don't confuse signaling with tones. Sometimes, we do use tones for signaling. That was from the days of analog transmission of user input. We have moved beyond that, one hopes... -----Original Message----- From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] Sent: Thursday, November 01, 2007 6:15 PM To: Dean Willis; Michael Procter Cc: sip@ietf.org Subject: RE: DTMF timing (was Re: [Sip] INFO ...) > -----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 Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ 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
- Re: [Sip] INFO: A recap, sense of consensus and a… Paul Kyzivat
- RE: [Sip] INFO: A recap, sense of consensus and a… Elwell, John
- Re: [Sip] INFO: A recap, sense of consensus and a… Adam Roach
- [Sip] INFO: A recap, sense of consensus and a pro… Dean Willis
- Re: [Sip] INFO: A recap, sense of consensus and a… Robert Sparks
- RE: [Sip] INFO: A recap, sense of consensus and a… Sanjay Sinha (sanjsinh)
- Re: [Sip] INFO: A recap, sense of consensus and a… Adam Roach
- [Sip] Mutual subscriptions Frank W. Miller
- Re: [Sip] INFO: A recap, sense of consensus and a… Robert Sparks
- Re: [Sip] INFO: A recap, sense of consensus and a… Paul Kyzivat
- Re: [Sip] INFO: A recap, sense of consensus and a… Paul Kyzivat
- RE: [Sip] INFO: A recap, sense of consensus and a… Henry Sinnreich
- RE: [Sip] INFO: A recap, sense of consensus and a… Frank W. Miller
- RE: [Sip] INFO: A recap, sense of consensus and a… Hadriel Kaplan
- Re: [Sip] INFO: A recap, sense of consensus and a… Robert Sparks
- Re: [Sip] INFO: A recap, sense of consensus and a… Dean Willis
- Re: [Sip] INFO: A recap, sense of consensus and a… Dean Willis
- Re: [Sip] INFO: A recap, sense of consensus and a… Dean Willis
- Re: [Sip] INFO: A recap, sense of consensus and a… Dean Willis
- Re: [Sip] INFO: A recap, sense of consensus and a… Robert Sparks
- Re: [Sip] INFO: A recap, sense of consensus and a… Adam Roach
- Re: [Sip] INFO: A recap, sense of consensus and a… Paul Kyzivat
- Re: [Sip] INFO: A recap, sense of consensus and a… Paul Kyzivat
- Re: [Sip] INFO: A recap, sense of consensus and a… Adam Roach
- Re: [Sip] INFO: A recap, sense of consensus and a… Paul Kyzivat
- RE: [Sip] INFO: A recap, sense of consensus and a… Francois Audet
- Re: [Sip] INFO: A recap, sense of consensus and a… Robert Sparks
- RE: [Sip] INFO: A recap, sense of consensus and a… Francois Audet
- Re: [Sip] INFO: A recap, sense of consensus and a… Paul Kyzivat
- RE: [Sip] INFO: A recap, sense of consensus and a… Christer Holmberg
- Re: [Sip] INFO: A recap, sense of consensus and a… Robert Sparks
- RE: [Sip] INFO: A recap, sense of consensus and a… Christer Holmberg
- Re: [Sip] INFO: A recap, sense of consensus and a… Dean Willis
- Re: [Sip] INFO: A recap, sense of consensus and a… Dean Willis
- RE: [Sip] INFO: A recap, sense of consensus and a… Hadriel Kaplan
- Re: [Sip] INFO: A recap, sense of consensus and a… Adam Roach
- Re: [Sip] INFO: A recap, sense of consensus and a… Dean Willis
- Re: [Sip] INFO: A recap, sense of consensus and a… Adam Roach
- RE: [Sip] INFO: A recap, sense of consensus and a… Sanjay Sinha (sanjsinh)
- RE: [Sip] INFO: A recap, sense of consensus and a… Hadriel Kaplan
- Re: [Sip] INFO: A recap, sense of consensus and a… Adam Roach
- Re: [Sip] INFO: A recap, sense of consensus and a… Adam Roach
- RE: [Sip] INFO: A recap, sense of consensus and a… Hadriel Kaplan
- Re: [Sip] INFO: A recap, sense of consensus and a… Adam Roach
- Re: [Sip] INFO: A recap, sense of consensus and a… Paul Kyzivat
- RE: [Sip] INFO: A recap, sense of consensus and a… Christer Holmberg
- Re: [Sip] INFO: A recap, sense of consensus and a… Paul Kyzivat
- RE: [Sip] INFO: A recap, sense of consensus and a… Francois Audet
- RE: [Sip] INFO: A recap, sense of consensus and a… Hadriel Kaplan
- RE: [Sip] INFO: A recap, sense of consensus and a… Hadriel Kaplan
- RE: [Sip] INFO: A recap, sense of consensus and a… Christer Holmberg
- Re: [Sip] INFO: A recap, sense of consensus and a… Dean Willis
- RE: [Sip] INFO: A recap, sense of consensus and a… Sanjay Sinha (sanjsinh)
- Re: [Sip] INFO: A recap, sense of consensus and a… Adam Roach
- Re: [Sip] INFO: A recap, sense of consensus and a… Paul Kyzivat
- RE: [Sip] INFO: A recap, sense of consensus and a… Francois Audet
- RE: [Sip] INFO: A recap, sense of consensus and a… Hadriel Kaplan
- RE: [Sip] INFO: A recap,sense of consensus and a … Elwell, John
- DTMF timing (was Re: [Sip] INFO ...) Dean Willis
- RE: DTMF timing (was Re: [Sip] INFO ...) Kevin Attard Compagno
- RE: DTMF timing (was Re: [Sip] INFO ...) Michael Procter
- Re: DTMF timing (was Re: [Sip] INFO ...) Dean Willis
- RE: DTMF timing (was Re: [Sip] INFO ...) Hadriel Kaplan
- RE: DTMF timing (was Re: [Sip] INFO ...) Eric Burger
- RE: [Sip] INFO: A recap, sense of consensus and a… Eric Burger