[asterisk-bugs] [Asterisk 0010058]: Asterisk rfc2833 DTMF fails with SIP service providers

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=10058 
====================================================================== 
Reported By:                tracinet
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   10058
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     acknowledged
Asterisk Version:           1.4.5 
SVN Branch (only for SVN checkouts, not tarball releases): N/A  
SVN Revision (number only!):  
Disclaimer on File?:        No 
Request Review:              
====================================================================== 
Date Submitted:             06-25-2007 16:03 CDT
Last Modified:              11-15-2007 06:03 CST
====================================================================== 
Summary:                    Asterisk rfc2833 DTMF fails with SIP service
providers
Description: 
I have been hunting down this problem now for over a month, thinking it was
a problem with my Polycom phone not passing RFC2833 properly.  So I decided
to take the Polycom out of the equation and set up a Dial statement that
would have asterisk send DTMF digits instead of the phone like this:

exten => 5555555555,1,Dial(SIP/sip_provider/5555555555,20,D(123456789))

(the 555 number represents my local landline).  So when I call the number
from my IP phone (Polycom, Linksys, Cisco - does not matter), asterisk
places a call out to one of my SIP service providers (have tested this with
Level 3 and Global Crossing) and when I answer the landline, I hear the
first digit and then silence until asterisk finished sending the remaining
digits and then 2-way audio is enabled on the call and talking can begin. 
The problem is that 8 of the 9 digits were not heard - only the 1st one
was.

Here is my sip.conf entries:

[general]
disallow = all
allow=ulaw
port = 5060                     
context = incoming              
maxexpirey=180
defaultexpirey=160
canreinvite=no
srvlookup=yes
videosupport=no
nat=no
tos=reliability
dtmfmode=rfc2833

[sip_provider]
type=friend
username=123456789
secret=password
host=10.0.0.1
disallow=all   
allow=ulaw
maxexpirey=15
relaxdtmf=yes
dtmfmode=rfc2833 
nat=no
insecure=very   
canreinvite=no
promiscredir=yes

I have tested this on MANY versions of asterisk from 1.2.10 all the way up
to 1.4.5 (with or without zaptel hardware installed).

I have realized that some phones that are set to RFC2833 also send out
tones inband as well, which makes this bug hard to reproduce if you are
depending on the phone to generate the tones.  Once you use a phone like
the Polycom SP430 that only sends RFC2833 tones when configured to do so,
the bug is very noticeable and makes the system unusable.  Take the phone
out of the mix like I have above and you quickly realize the issue is not
the phone at all.

Have had engineers at the various service providers look at this problem
and they insist the issue is a bug in asterisk and one has gone so far to
state that a Digium tech said it was a problem with asterisk timing and to
just use inband.  This is unacceptable as inband is not reliable.  Thank
you in advance for your assistance with this.
====================================================================== 

---------------------------------------------------------------------- 
 oej - 11-15-07 06:03  
---------------------------------------------------------------------- 
Any update, File?

/Housekeeping 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
11-15-07 06:03  oej            Note Added: 0073700                          
======================================================================