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.
Then there's the question of decoding the 2833 stream and backhauling
it from the RTP-processing DSP element up to the application that's
running at the control layer. From what the people who build
decomposed gateways sometimes tell me, I've surmised that this may
not be the easiest thing to do efficiently. This also applies to
application built using a control "application servers" and a media
server, since we don't generally bother to negotiate different
endpoints for the 2833 stream, so it just follows the path to the
media server.
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.
So, that's why I'd like to see real-world measurements in real-world
large-scale applications that actually use DTMF.
--
Dean
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
