DTMF problem starting with 1.3.8

[GoogleCodeExporter]

1. Install or upgrade to 1.3.14
2. Call or respond
3. On a Nexus One with sipdroid I hear the other side perfectly, but the
other side hears nothing.

What is the expected output? What do you see instead?
To be able to hear eachother.

What version of the product are you using? On what operating system?
1.3.14

Which SIP server are you using? What happens with PBXes?
Asterisk

Which type of network are you using?
WLAN

Please provide any additional information below.

Original issue reported on code.google.com by disco...@gmail.com on 17 Feb 2010 at 7:11

[GoogleCodeExporter]

Let me know if we need a pcap file to help sort out whats going on... 

Original comment by brandonn...@gmail.com on 19 Feb 2010 at 7:22

[GoogleCodeExporter]

Seems to have not been any movement on this issue for a few weeks. Anyone have 
any
ideas? 

Original comment by brandonn...@gmail.com on 9 Mar 2010 at 9:41

[GoogleCodeExporter]

any one had a chance to test 1.4 yet? 

Original comment by brandonn...@gmail.com on 10 Mar 2010 at 10:44

[GoogleCodeExporter]

DTMF still isn't fixed, and the issue where the dialer will immediately die 
after you
exit a call and open it again also is still there.  Initial tests of the sound
quality suggest improvement though...

Original comment by disco...@gmail.com on 10 Mar 2010 at 11:41

[GoogleCodeExporter]

the nexus one issue seems to be resolved. 

Original comment by brandonn...@gmail.com on 30 Mar 2010 at 12:09

[GoogleCodeExporter]

@brandonnolte: you referring to the original sound quality issues or DTMF ?

Original comment by disco...@gmail.com on 31 Mar 2010 at 12:56

[GoogleCodeExporter]

I still have a lot of issues with DTMF on the Nexus One.  Some VRU work okay 
with
sipdroid + n1, some don't.  

1.3.7 works fine so its pretty clearly an issue with sipdroid and not some 
inherently
flaw with the N1.  

I live in Japan and I use voip primarily to call insurance companies and banks 
and
other scum in the US.  Given the very early or late hour that I must make these 
calls
during US business hours to said scumbags, encountering an inability to 
successfully
enter strings of numbers greatly increases the chances of me smashing the phone 
into
small pieces.   

Please help me fix this.

Original comment by disco...@gmail.com on 19 Apr 2010 at 11:54

[GoogleCodeExporter]

Sipdroid v1.4.7 running on Nexus One with Android 2.1. Using it over WiFi to a 
local Asterisk v1.4.29 server. 
All calls forced to g711 mu-Law codec, IP phones and Sipdroid WiFi network on 
separate physical LAN from 
general user and server to assure good QoS for VoIP.

Observation: DTMF audible feedback occurs about 1 second after button push and 
it appears that is also when 
the Asterisk server detects it. If you don't wait until after the tone finishes 
before pushing the next number 
button the tone is either lost or corrupted.

End result: Sipdroid is useless in accessing voice mail or any IVR site like 
your local bank. I am a lost to 
understand why this defect is prioritized as "medium" instead of something 
higher.

DTMF can be an issue on VoIP with several different transport mechanisms. All 
the IP phones and ATAs that I 
have used allow a way to enable/disable and prioritize how DTMF is sent ("in 
band", "SIP info" or 
RFC2833/AVT). I don't see any way to control this in Sipdroid and depending on 
your VoIP provider and the 
codec used it does make a difference. Codec selection and prioritization is 
handled well in Sipdroid, perhaps 
DTMF methods could be handled the same way.

Regardless of DTMF method selection, Sipdroid should not lose or corrupt the 
sequence of number button 
pushes: If it can't send them in real time it should queue them and send them 
out at as it can. I've seen a 
number of cordless phones that do it that way.

Original comment by s.tod.fi...@gmail.com on 29 May 2010 at 2:39

[GoogleCodeExporter]

@s.tod.fitch

Thank you for your comments!   I'm glad to have someone else back me up on 
this. 
What you've said is exactly what I've observed - if you hold the button down a 
long
time and go very slowly, the chances of success are higher.  A 4 digit pin code 
is
one thing, but a 16 digit credit card is next to impossible.

Original comment by disco...@gmail.com on 29 May 2010 at 11:54

[GoogleCodeExporter]

Same exact issue and same exact observation as s.tod.fitch.  If I dial DTMF 
numbers 
*super slow* on sipdroid, they are recognized.  If I dial the numbers without 
slowing myself WAY down, the tones are lost/corrupted.

I agree:  sipdroid needs options for DTMF mode (inband, info, rfc2833), and 
should 
also queue dtmf if entered too fast.

Please understand, this isn't an issue of just needing to push the numbers 
slower, 
you have to push them with at least a 1second delay or data is lost.  Please 
fix :)

Original comment by samwathe...@gmail.com on 29 May 2010 at 11:55

[GoogleCodeExporter]

PLEASE escalate this issue to HIGH priority.  This defect prevents many of us 
from 
productively using sipdroid.  There are SO many times that one needs to enter a 
DTMF / series of DTMF tones in order to check voicemail, use callback features, 
etc.  This is the number 1 issue preventing me from using sipdroid as a 
full-fledged 
POTS replacement.

Thank You

Aside from this problem, sipdroid is FANTASTIC

Original comment by samwathe...@gmail.com on 30 May 2010 at 12:01

[GoogleCodeExporter]

I think a sensible compromise would be to permit the selection of DTMF mode via 
configuration option - possibly at a per-account (PBX?) level.  There are only 
3 possibilities: RFC-2833, in-band, and SIP Info.

I can confirm that switching to SIP Info in my case (using an asterisk PBX) 
resolved the DTMF issue completely.

Devs - if you like, contact me privately and I can perhaps assist in the 
implementation of this feature and submit a patch for your approval.

Original comment by goatbo...@gmail.com on 22 Jun 2010 at 4:25

[GoogleCodeExporter]

I'd suggest to merge back the SIP info DTMF method and to add the In-band 
signalling, as some SIP gateways don't generate DTMF when going to landline.

Original comment by marcu...@gmail.com on 25 Jun 2010 at 12:31

[GoogleCodeExporter]

How much $$$ does someone want to fix DTMF on sipdroid?   I'm ready to pay, its 
useless as-is...

Original comment by disco...@gmail.com on 30 Jul 2010 at 1:12

[GoogleCodeExporter]

Search for Linphone on the market, works pretty well.

Original comment by stane...@gmail.com on 1 Aug 2010 at 1:29

[GoogleCodeExporter]

I have spent WAY too much time getting all of this configured.  I finally have 
all inbound and outbound calls correctly relaying to my Android phone.  
However, now I cannot make any calls to systems that require dialpad input.  (I 
was only able to confirm my number in Google Voice by playing a number tone 
through my pc.)  

I've tried changing the options in pbxes.org for dtmf from "auto" to "info" to 
"inband", etc., but none resulted in a consistent dial pad operation.

I tried Linphone with the basic settings for pbxes, but it never connected 
properly...some sort of indicator if logon was successful would be nice)

Original comment by jeremiah...@gmail.com on 5 Aug 2010 at 9:50

[GoogleCodeExporter]

hi everyone,because my server not support info/RFT2833 ,so sipdriod dtmf 
feature not work.it not work,anyone can give an idea?do i need to send the 
standar dtmf tones with rtp packet?

Original comment by pfingo....@gmail.com on 6 May 2011 at 12:57

[GoogleCodeExporter]

CSIPSimple seems to support DTMF just fine...

http://code.google.com/p/csipsimple/

Original comment by di...@lotek.org on 6 May 2011 at 1:06