Subject: RE: [SIP] DTMF

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Thu, 10 Aug 2000 18:33:11 -0700

Hi Henning,

> - sending keyboard input as envisioned here has nothing to do with
> session setup or control or signaling

I would argue that certain DTMF actions do have some effect over session
control - the classic example is triple star or long pound on calling card
systems. In my mind it is these class of actions that are the driving the
need for DTMF to be "split off" to one (or more perhaps) application servers
(in addition to the voice media endpoint!!).

The need for and method of forking the DTMF has of course has been the
eternally revisited sticking point. 

Am I missing your point? 

> - RTP with redundancy is at least as reliable as SIP transport
> 
> - REFER and 3pcc can be used to redirect RTP streams wherever they are
> needed, either separate from or jointly with the audio stream

Looking at the cc-transfer draft I can't see how this relates to solving the
above probem as it relates to DTMF streams (and DTMF does not seem to be
mentioned anywhere). Can you provide any more specific pointers ?

I sorry to ask _again_ but are you asserting that you don't need to send the
DTMF to multiple entities (voice endpoint and IVR application server)? If
not how are you proposing to solve the above classic problem? 

Thanks,

Robert.

-- My opinions are my own. I tried selling them once but everybody
	seems to already have one. -- 
> - a number of implementations already support the RFC 2833 mechanism -
> why should they support another mechanism?
> 
> As Colin points out and has been raised on the list before in a
> different context, if we're into text communications (full keyboard
> set), the RTP text payload type may also be appropriate. 
> 
> Thank you.
> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 10 Aug 2000 21:53:10 -0400

> (in addition to the voice media endpoint!!).

It's not signaling in the VoIP sense. That these keys happen to have
consequences for the call is no different than if I were to use a web
browser and HTTP to somehow manipulate the call (indirectly invoking
some SIP action, in our context). This does not mean that HTTP is
suddenly a signaling protocol that should be carried in SIP.

One mechanism to 'split off' DTMF is to simply do an INVITE for the same
call, different call leg, where the SDP only allows 'tones'. Another,
more transparent one, is to have any box near the audio destination copy
the relevant RTP bits to whoever needs them. (This would be the address
specified in the SDP.)