Subject: RE: [Sip] INFO: A recap,sense of consensus and a proposal for direction.

From: "Elwell, John" <[email-masked]>
Date: Thu, 01 Nov 2007 11:07:52 +0000

Hadrial,

You wrote:
> The sticky part in my mind has always been what to do if both 
> info-dtmf were negotiated and 2833/4733 was offered/answered. 
>  Or even what to do with in-audio tones.  I *think* the 
> answer is info-dtmf should trump 2833 - i.e., if you 
> negotiated info-dtmf only do that, for a variety of reasons; 
> but with delayed SDP offers that would mean you'd always end 
> up using info-dtmf when you could have done 2833 instead.  
> And I can see the argument for "do both", and that's what 
> kpml did except it has the suppression/<pre> concept, but I 
> assumed that was due to pattern matching being inconsistent 
> with in-band event sending one-at-a-time.  But I still think 
> info-dtmf trumping would be right, because the tones will get 
> to the far end if they should.
[JRE] Performance is a consideration with DTMF, because the speed with
which the user receives a response from the server can have impact on
the user experience. RFC 2833 is always likely to get through quicker.

John

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Dean Willis <[email-masked]>
Date: Thu, 1 Nov 2007 12:39:52 -0500

> the user experience. RFC 2833 is always likely to get through quicker.

That's an interesting assertion. While I'm inclined to agree that  
your assertion is likely to prove correct, I'm wondering: Does  
anybody out there have real-world measurements on this?

--
Dean

---

From: "Kevin Attard Compagno" <[email-masked]>
Date: Thu, 1 Nov 2007 19:00:07 +0100

Apologies for butting in, it's my first post to this list...

My understanding is:

It's not that RFC2833 DTMF delivery arrives quicker that is the point, but that it gets delivered with the rest of the real-time audio inside the RTP stream, timestamped appropriately to insert the tone at the correct point in time within the stream.

---
Kevin Attard Compagno

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: 01 November 2007 18:40
To: Elwell, John
Cc: sip List; Paul Kyzivat; Adam Roach
Subject: DTMF timing (was Re: [Sip] INFO ...)

--
Dean

---

From: "Michael Procter" <[email-masked]>
Date: Thu, 1 Nov 2007 13:20:54 -0700

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.
 
Regards,
 
Michael

________________________________

From: Kevin Attard Compagno [mailto:[email-masked]]
Sent: Thu 01/11/2007 18:00
To: [email-masked]
Subject: RE: DTMF timing (was Re: [Sip] INFO ...)

My understanding is:

---
Kevin Attard Compagno

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: 01 November 2007 18:40
To: Elwell, John
Cc: sip List; Paul Kyzivat; Adam Roach
Subject: DTMF timing (was Re: [Sip] INFO ...)

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 1 Nov 2007 16:18:33 -0500

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 1 Nov 2007 18:15:07 -0400

> 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.

> 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

---

From: "Eric Burger" <[email-masked]>
Date: Sun, 4 Nov 2007 09:17:19 -0800

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:[email-masked]] 
Sent: Thursday, November 01, 2007 6:15 PM
To: Dean Willis; Michael Procter
Cc: [email-masked]
Subject: RE: DTMF timing (was Re: [Sip] INFO ...)

> 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.

> 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
[email-masked] for questions on current sip Use
[email-masked] 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.

---

From: "Eric Burger" <[email-masked]>
Date: Sun, 4 Nov 2007 09:21:20 -0800

Wasn't this why we were going to publish the perils of INFO? 

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Tuesday, October 30, 2007 6:02 PM
[snip]
I also know that other SDOs are looking into using INFO for certain
things, so I think it would be really good to define a proper mechanism
before they also start to use INFO as it's used today (with all the
problems people have listed).
[snip]