Subject: RE: [SIP] DTMF digit handling

From: "Culpepper, Bert" <[email-masked]>
Date: Mon, 10 Jul 2000 14:30:29 -0500

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Monday, July 10, 2000 11:54 AM
> To: Jonathan Rosenberg
> Cc: Fairlie-Cuninghame, Robert; [email-masked]'
> Subject: Re: [SIP] DTMF digit handling
> 
> 
> Jonathan Rosenberg writes:
>  > Note that I am still cautious about these kinds of things. They
>  > basically imply that providing the service *relies* on the origination
>  > point correctly doing DTMF. There is such a wide range of access
devices
>  > supporting SIP; counting on each and every one of them everywhere
always
>  > performing DTMF correctly seems dangerous. So, the safe way to get the
>  > DTMF is to terminate the entire media stream, so that you can do your
>  > own detection if needed.. In any case, most DTMF-based apps often also
>  > allow for speech recognition, which requires termination of the media
>  > stream at the application point anyway.
> 
>    I guess I'm not as worried here: if you're using
>    a codec which isn't good at transporting DTMF like
>    G.723 or G.729, you have pretty good incentive to
>    get your DTMF codec ala RFC2833 correct. Also: things
>    like IP phones or PC's don't need DTMF detectors 
>    for local digit collection at all. If the far
>    end wants to see DTMF for an IVR, say, the
>    phone is going to have to manufacture DTMF
>    anyway. If anything, I'd expect that the
>    likelihood of getting NSE's correct is a lot
>    higher than injecting DTMF waveforms into a
>    G.711 stream...
> 
> 		Mike
> 

RFC2833 solves distortion issues with low bit-rate codecs.  And I,
myself don't see the use of DTMF with IP Phones or PCs.  Where
I see DTMF in a SIP network is when SIP (and RTP) carries PSTN
traffic.  We can either support the existing services (and new services
possible with IP networks) offered by telecommunications service
providers or tell them SIP in part of their network won't work if they
are not willing to accept the loss of voice quality and some existing
service features.  However, no extensions to SIP or the media
gateway control protocol are needed if service deployment is
limited to the call agent on the gateway controller, no loss of voice
quality occurs and any existing service I can think of can be provided
unchanged.  Let's rule out 3rd-party call control and the issue goes
away :).

> 
> _______________________________________________
> 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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 11 Jul 2000 01:14:44 -0400

"Culpepper, Bert" wrote:
> service features. 

I really, REALLY hate "threats" like this, which are occassionally made
on the list (in fact, often around DTMF). THings of the form "but if you
don't do X, service provids will use some other protocol, so you better
extend SIP to do X for me". Lets debate the technical issues and stay
away from these kinds of tactics.

-Jonathan R.
-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com