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

[Hadriel Kaplan <HKaplan at acmepacket.com>]

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis at 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 at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip