Hi Pekka,

> > Unless I'm missing something, the DTMF 'C' digit refers exactly to what
> > you're trying to achieve with 'p' and ','
> >
> > Check TS 11.11 Table 12.  'C' is mentioned as the DTMF Control digit
> > separator from TS 02.07.
>
> You mean binary code 0b1100 aka hex code 0xC? It would be otherwise
> known as DTMF digit 'A'. Welcome to wonderful world of phones.
>
> Have a peek in src/smsutil.c to_semi_octet().
>

Funny part is that I wrote that function :)  But actually you're absolutely 
correct.  I forgot how context sensitive this specification is.  Just so we're 
on the same page:

24.008 Table 10.5.118 maps BCD thus:
0-9, 10 -> '*', 11 -> '#', 12-> 'a', 13-> 'b', 14->'c', 15 -> endmark

TS 11.11, 51.011 and 31.102 define the BCD SIM storage thus:
0-9, 10-> '*', 11->'#', 12->'C' DTMF Control Digit separator, 13 -> 'D' Wild 
value. 14 -> RFU, 15->Endmark.

DTMF digits have yet another coding.  The current implementation is actually 
correct,  so you can safely ignore most of what I said in the last message.

> I'm afraid the modem driver has to implement pause either by itself or
> with some modem-specific command.
>
> Each DTMF digit is sent using 24.008/Q.931 "Start DTMF" message,
> followed by "Stop DTMF". Start DTMF contains DTMF digit encoded as a
> single IRA character (from the set of 0-9, *, # and A-D). If there is
> pause (like one defined in 02.07), modem just don't send next "Start
> DTMF" for 3 seconds.
>
> AT+VTS tries to hide that, you just give digit and its duration.

Problem is, AT+VTS only handles true DTMF characters according to 27.007.  Any 
pauses have to be simulated or sent directly using ATD.  If we are going to 
support such dialstrings, we have to do this in the core daemon, not the 
driver.

> I'd propose that we allow dial strings in phone numbers, like,
>
> "8188080p1234#pp6789#" (Nokia)
> "8188080(a)1234#,,6789#" (V.250)

Yuck.  Lets come up with one format to support, if possible.  How does CDMA 
handle this nonsense?

>
> Ofono should also accept dial strings like
>
> "8188080,1234#,6789#ABCD#"
>
> where the , means that voicecall should start sending DTMF digits 3
> seconds after first RINGING.

A significant number of modems do not return from ATD until the call is 
connected, not just ringing.  So unless we use a different multiplexer channel 
for DTMF such behavior cannot be guaranteed.  Even with a multiplexer this 
probably won't work with a significant number of modems.

>
> If a string starting with 'p' or '@' is given to SendTones() before
> call is connected, driver waits until call is connected before sending
> it to network. If call is already connected, ',', 'p' or '@' are
> interpreted as pause of 3 seconds.

Yuck.  I suggest we leave SendTones as is.  If we support this behavior it 
should be specified by the dialing number.

The biggest issue is that there is no progress synchronization as you've 
already mentioned.   Most of the modern platforms need to generate audible 
events whenever a DTMF is signaled since this is (potentially) no longer 
handled by the modem.   The current API was actually intended to be used only 
as a 'slave' by a controlling entity that interacts with UI, audio framework 
and oFono.

While I'm sure we can accommodate a state machine to handle all of this 
nonsense inside oFono, I'm no longer convinced we should.

First step should be to come up with a nice, clean API for all of this that 
will report DTMF progress, and has a realistic chance of actually being 
implemented across modems and technologies.

Regards,
-Denis