Telephony API contribution: Sending DTMF codes

[Gergely Kis]

Dear Android Contributors,

Now that we have Gerrit back up and running again, we would like to
warm up the discussion about adding support for sending DTMF codes.
For convenience, here is a link to the old thread:

http://groups.google.com/group/android-contrib/browse_thread/thread/c8df8863d454bb7/bd52ebc68141f426

And here is the link for the original changesets:
https://android-review.googlesource.com/#/c/18745/
https://android-review.googlesource.com/#/c/18746/
https://android-review.googlesource.com/#/c/18747/

We actually had an updated version for Gingerbread, but it got lost
during the Gerrit hosting switch. We are working on an updated version
for ICS, so there is no need to restore that version.

We hope to get this contribution into AOSP, and hopefully into future
official platform releases as well. We have a developer available to
make any changes requested during review. We will submit the patches
ported to ICS in the next days.

In the meantime we have a few questions to the members of the Android
Telephony Team and the wider community:
1. Is there anything you would like us to change in the proposed API?
We had one addition in the lost patch compared to the old ones (apart
from addressing the review comments): a sendDtmf() method in
TelephonyManager which has the same signature as the sendDtmf in the
SIP stack, this will be included in the new patch as well.

2. TelephonyManager.isCallActive() / isCallHolding(): These methods
are
required, because the PhoneStateListener does not provide information
that is detailed enough whether the call is active or on hold.

One possibly better solution would be to add a
LISTEN_DETAILED_CALL_STATE
option and matching onDetailedCallStateChanged() method to the
PhoneStateListener, which would provide more detailed information
whether the call is active or on hold. Do you like this solution? Of
course better naming suggestions for this option / method would be
appreciated.

Best Regards,
Gergely

PS: I tried to send mail from my regular mail client, but it did not
appear in the list archive.

[Jean-Baptiste Queru]

FWIW, I can manually recover the "lost" patch sets if you know the
project, changeid and patchset that you would like back.

JBQ

--
Jean-Baptiste M. "JBQ" Queru
Software Engineer, Android Open-Source Project, Google.

Questions sent directly to me that have no reason for being private
will likely get ignored or forwarded to a public forum with no further
warning.

[Gergely Kis]

Hi Jean-Baptiste,

Thanks for the offer, but we don't need that. We are working on the
ICS patches already, and plan to submit them next week. In the
meantime it would really help our effort if somebody from the Android
Telephony team would look at our questions.

Thanks,
Gergely

2012/1/23 Jean-Baptiste Queru <j...@android.com>:

[Robert Greenwalt]

Hi Gergely,

1)  I've added some comments to the changes.

2) I think I'd prefer extending the existing PhoneStateListener to provide the needed phone state info.

Can you check out the dialer app does DTMF?  We shouldn't have two mechanisms - either yours should use theirs or they should use yours.

Thanks for working on this platform change!

R

[Gergely Kis]

Hi Robert,

Thank you very much for taking the time reviewing our patches.

To summarize, there are 2 main topics that you brought up:

1. Eliminate the duplication in the DTMF sending code (between the
DTMF service and the Dialer) -- sure, we will refactor it.

2. Include some sanity checks to make sure that the current active
call when mPhone.startDtmf() ... etc. is called is still the same call
the user intended to send the DTMF codes.

In order to make these sanity checks, we have to somehow retrieve the
identity of the call, and pass it along with the DTMF send request.

The call chain looks something like this:
DTMF sender app -> TelephonyManager ---- <<binder>> ---->
PhoneInterfaceManager (ITelephony implementation) ----> async dispatch
--> call to the internal Telephony API (e.g. startDtmf(),
getForegroundCall ... etc.)

Both the binder communication and the async dispatch may cause the
request to be queued, so that the active call changes by the time the
request gets there. We can certainly implement a mechanism to retrieve
the current foreground call's id inside the TelephonyManager, and pass
it along the DTMF send request, which we can check before we actually
start sending the DTMF codes. Do you think this is a good solution, or
you had something else in mind?

I have another question: Do you think the intent based interface makes
sense for sending DTMF codes? It looked like a good idea at the time,
but now I am not sure, since one has to deal with the TelephonyManager
directly anyway to check the call state, set up the phone listener ...
etc.

Best Regards,
Gergely

2012/1/26 Robert Greenwalt <rgree...@google.com>:

--
Kis Gergely
ügyvezető / CEO
MattaKis Consulting
Email: gerge...@mattakis.com
Web: http://www.mattakis.com
Phone: +36 70 408 1723
Fax: +36 27 998 622

[Robert Greenwalt]

On Fri, Jan 27, 2012 at 8:01 AM, Gergely Kis <gerge...@mattakis.com> wrote:

Hi Robert,

Thank you very much for taking the time reviewing our patches.

To summarize, there are 2 main topics that you brought up:

1. Eliminate the duplication in the DTMF sending code (between the
DTMF service and the Dialer) -- sure, we will refactor it.

2. Include some sanity checks to make sure that the current active
call when mPhone.startDtmf() ... etc. is called is still the same call
the user intended to send the DTMF codes.

In order to make these sanity checks, we have to somehow retrieve the
identity of the call, and pass it along with the DTMF send request.

The call chain looks something like this:
DTMF sender app -> TelephonyManager ---- <<binder>> ---->
PhoneInterfaceManager (ITelephony implementation) ----> async dispatch
--> call to the internal Telephony API (e.g. startDtmf(),
getForegroundCall ... etc.)

Both the binder communication and the async dispatch may cause the
request to be queued, so that the active call changes by the time the
request gets there. We can certainly implement a mechanism to retrieve
the current foreground call's id inside the TelephonyManager, and pass
it along the DTMF send request, which we can check before we actually
start sending the DTMF codes. Do you think this is a good solution, or
you had something else in mind?

I think it makes sense, but I'm hoping we'll also get feedback from others.  I think the call control API is a little sloppy now and doesn't do alot of this "indicate which call you want me to do X to" rigor.  I think it may be good to add it, but it may depend a bit on how difficult/expensive it is to do.  Take a look and let us know if you think it could be worth while.

Getting the current foreground call id doesn't help the app disambiguate - you may as well just have "do X on the current foreground call" style.  It seems like the app would need not only to find the current foreground id, but also find info about it - perhaps showing the phone number/contact info so the user is indicating "do X on my call to <BANK>" or programatically comparing the call info with scripts or other user-indicated intent.

I have another question: Do you think the intent based interface makes
sense for sending DTMF codes? It looked like a good idea at the time,
but now I am not sure, since one has to deal with the TelephonyManager
directly anyway to check the call state, set up the phone listener ...
etc.

Intents definitely seem like you're lobbing a request over the wall and hoping it hits your target.  I feel it makes more sense if we decide to remove the call-id targeting and just hope for the best.  The late runtime binding may be useful in erroring out on older versions of the system, but in general I find intents are best when you have unknown an destination or destinations for the action and I'm not sure we'd ever want/support multiple dtmf handlers.

R

[Gergely Kis]

Hi,

Just a small update and RFC:

I think we found a fairly simple and non-intrusive solution for making
sure that you send DTMFs to the call that you actually intended to
(not a bad thing when you consider phonebank passwords :) ).

The new PhoneStateListener method would look like this:
public void onPreciseCallStateChanged(int state, String[] addresses);

The values of the state parameter would match the Call.State enum values.

The addresses array would contain the addresses (usually phone
numbers) of the connected endpoints for the call. Unknown addresses
could be reported as a special UNKOWN_ADDRESS constant or empty
string.

The DTMF sending interfaces in TelephonyManager would look like this:

sendDtmf(String address, char c);

During sending the implementation would make sure that the call has a
connected connection with the specified address.

As an extra precaution we could also limit DTMF sending to calls with
a single connection. This would be a protection against an attacker
who can somehow add a second connection to a call while the send DTMF
request is in transit.

Also, DTMF codes could only be sent programmatically to calls with
known caller ids.

Do you like this proposal?

Best Regards,
Gergely

2012/1/31 Robert Greenwalt <rgree...@google.com>:

[Gergely Kis]

Hi,

We just uploaded the new version of the DTMF patch to Gerrit.

It is divided in 3 parts:

1. frameworks/base: https://android-review.googlesource.com/#/c/32820/
- Adds the APIs to TelephonyManager and PhoneStateListener
- Adds the actual implementation to the CallManager and TelephonyRegistry

2. packages/apps/Phone: https://android-review.googlesource.com/#/c/32821/
- The ITelephony interface implementations required by the TelephonyManager API.
- The actual work is forwarded to the framework CallManager.

3. development/samples/DtmfTester:
https://android-review.googlesource.com/#/c/32810/
A detailed test application where you can try out the different
features of the new APIs, including:
- precise call state tracking
- sending DTMF codes

You need to pull all 3 patches to your tree to test it (well the 3rd
one is optional, if you want to write your own test app).

We look forward to your comments / suggestions.

Best Regards,
Gergely

2012/2/2 Gergely Kis <gerge...@mattakis.com>:

[Gergely Kis]

Hi,

Now, that March is over and we survived all the April 1st jokes, would
it be possible to somehow expedite the review of this patch? There are
at least 93 people who are interested in this, according to the
following issue:
http://code.google.com/p/android/issues/detail?id=1428

Best Regards,
Gergely

2012/2/17 Gergely Kis <gerge...@mattakis.com>:

[Gergely Kis]

Hi,

Any news about this? No one at Google cares enough about Telephony
improvements to even look at it?

Best Regards,
Gergely

2012/4/2 Gergely Kis <gerge...@mattakis.com>:

[Jean-Baptiste Queru]

I'll overstep my bounds a bit and answer somewhat on their behalf:
they've been incredibly busy for the last 12+ months. They've dealt
with a CDMA device, a CDMA+WiMAX one, two CDMA+LTE ones, plus a fair
amount of GSM sprinkled on that, all that while adapting to the
changes happening on all networks. I know that they care about
telephony very much, but that they are also on the critical path for
many releases and need to first make sure that telephony issues don't
prevent devices from shipping.

JBQ

[Gergely Kis]

Hi,

The problem is that polite requests don't seem to attract any
attention, however emails with a bit more direct tone seem to work
better (I observed this on multiple occasions.). At least now I have a
developer, who promised that he will look into it. (Thanks Joe!)

It would be much better, if there was a project manager for AOSP
contributions, whose main role was to aid communication between
(wannabe) contributors, and the actual Google developers, fight for
review resources with the internal subsystem leads/PMs ... etc. You
would be great for this position, but you seem to have too many roles
to count already in AOSP. :)

You would think (or at least I would) that a project as big as Android
would have the budget for one more person in the AOSP team. I can
understand why the upper management might think it does not make sense
from a financial point of view, because the number of external patches
is relatively low. However, you don't have the review bandwidth to
process even these patches. So we have a catch 22-like situation.

Best Regards,
Gergely



2012/4/26 Jean-Baptiste Queru <j...@android.com>:

[Jean-Baptiste Queru]

As you've noticed, Deckard is now looking at changes again, which will
make it much easier to look at contributions. Tools-wise, we're not
too far from where we were last July.

Also, on the bright side, I've extinguished the fires I was fighting,
and my backlog is small enough that I should have enough time to look
at contributions again, at last.

Spring is here. I'm feeling optimistic.

JBQ