I frequently use to dial a number follow by the destination number (VOIP
service)

Never have such issue, I believe the DTMF tones are sent out when the call is
established.

Did you notice during ringing that it start to send out DTMF tones?

DTMF tones are being sent out only after the call is established.  The problem
is that there is no pause before sending out DTMF tones for the destination
number.

The number I dial looks like this: 18664947292pp<destination_number>.  I'd like
the phone to pause for some time _after_ the call has been answered before
sending out DTMF tones for the destination number.

If I change the stored number to 18664947292p0p<destination_number> (add a 0 in
between the pauses),  DTMF tones for the 0 is sent out as soon as the call is
answered, then there's a pause, followed by DTMF tones for the destination
number.  This has the desired effect, but inserting the 0 is ghetto IMO.

Comment 3 Andre Klapper 2009-12-22 21:29:32 UTC

Just to make this sure:
This is not a duplicate of either bug 5505, bug 5998 or bug 6139?

It's not a duplicate of 5505, 5998 or 6139.

Can you give some example numbers please.
Of course you don't have to provide real calling card number

I understand your point it's not pausing long enough, but I don't see that
causes any direct problem for me ie not entering calling card numbers etc.

If you're in the US, I could tempoararily add your phone number to my calling
card account as one of the registered numbers.  Of course, I'll need a phone
number for that :)

Actually I only need the phone number you're dialing to to enter your calling
card number to check the problem.

here is an example:
+1 604 555 5555,,333
(i expect my phone to call the number at the "," I expect it to pause and then
dial the 333 after it has connected. 

here is the number i dial often:
+1(604) 953-3333 ,,1,1,50490

what might be missing from my previous post is:
"333" is the extension number that I have to dial once the call has been
connected. on my palm centro and old nokia 6100 a "," was a pause between DTMF
tones. there is no pause on the n900!

Here's a test case:

Call 1.800.331.0500 (AT&T wireless customer service).  Once the call is
answered, you hear a welcome message.  After the welcome message, the number
you are calling from is narrated back to you and you are asked to press 1 if it
is the same number you are calling about (let's assume that it is).

Try to get the N900 to dial 18003310500 and then pause for a few seconds before
sending out DTMF for the '1' (I tried 18003310500pppp1).  You'll see that the
'1' is sent immediately after the call is connected.  No pause.

*** This bug has been confirmed by popular vote. ***

I can confirm this issue. I am following instructions on Your Call World
website, a cheap calls provider that I use regularly, see:
http://yourcallworld.com/help/hints_tips.aspx

Number I'm dialling is: 01216622662p0048xxxxxxxxx. I get connection with access
number, however I instantly get the automated voice message that the target
number I am trying to dial is incorrect.

However, when I try dialling exactly the same number on Nokia E71 - it works
without hassle and I get connection with target number straight away.

Simply speaking: this is an evident bug that needs addressing.

Update: it seems to (In reply to comment #2)
> If I change the stored number to 18664947292p0p<destination_number> (add a 0 in
> between the pauses),  DTMF tones for the 0 is sent out as soon as the call is
> answered, then there's a pause, followed by DTMF tones for the destination
> number.  This has the desired effect, but inserting the 0 is ghetto IMO.

Confirmed. When I dial 01216622662p0p0048xxxxxxxxx - it works.

Comment 15 Andre Klapper 2009-12-30 14:09:25 UTC

This has been fixed in package
telepathy-ring 1.0.4+0m5
which is part of the internal build version
2.2009.42-9
(Note: 2009 is the year, and the number after is the week.)
This is not included in 1.2009.42-11, but in the upcoming "PR1.1" release.

A future public update released with the year/week later than this internal
build version will include the fix. (This is not always already the next public
update.)
Please verify that this new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.


To answer popular followup questions:
 * Nokia does not announce release dates of public updates in advance.
 * There is currently no access to these internal, non-public build versions.
   A Brainstorm proposal to change this exists at
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/

Comment 16 Andre Klapper 2010-01-14 12:25:51 UTC

The problem reported here should be fixed in the update released today for
public: The Maemo5 update version 2.2009.51-1 (also called "PR1.1" sometimes).
Please leave a comment if the problem is not fixed for you in this update
version.

I can confirm this has been fixed.