Retrieving detailed disconnect cause value from telephony framework.

[Roger Madsen]

Hi.

Some operators wants the phone app to show a more detailed disconnect
cause message. Some even want the exact cause value number to be
displayed together with the disconnect message text. This is to make
it easier for the operator’s customer support to know what problems
the customer might have with making a call, or why calls are dropped
and so on.

Currently the Android telephony framework have no support for this.
The only call cause values available to the UI are the ones defined in
the DisconnectCause enum in Connection.java.

There are different ways of solving this and I would like your input
on which solution you prefer and if this is something you would take
in as a contribution and of course if you have any other suggestions
on how to solve this.

One solution is to store the exact cause value in Connection.java when
retrieved in onRemoteDisconnect in GsmConnection.java (or
CdmaConnection) and then add a interface to retrieve it. We have
called it getRawDisconnectCause (getPhoneTypeSpecificDisconnectCause
is another name we have thought of). This has very little impact on
telephony framework and with this implementation we have both a way to
get a more simplified generic cause value or get the exact phone type
specific cause value when needed. The “raw” cause value is of course
not always set and if it’s not we check with getDisconnectValue if
it’s power off or any other cause value not set by the platform. This
is the current implementation we are using since this has least impact
on current code but it’s maybe not the best long term contributable
solution.

Another solution is to change the telephony framework to always return
the exact phone type specific cause value and let the phone app decide
how to handle the different cause values instead.

As I understand the thought behind the current design in telephony
framework you want GsmConnection and CdmaConnection to handle the
“raw” cause value from the platform and translate that value to a more
generic value in DisconnectCause enum in Connection.java to let the
phone app not care too much about what type of phone it is. But that
enum already today have a few CDMA and GSM specific cause values. So
the phone app has to check if it’s a GSM or CDMA phone type when
showing a disconnect message anyway. Maybe a better solution is to
just return the “raw” cause value and then let the phone app handle
what to do with it? Some generic cause value are of course still
needed like power off or out of service.

What are your thoughts on this?

BR
/Roger

[Gergely Kis]

Hi,

2013/5/3 pakali senget <paka...@gmail.com>:
[...]
>
> I am working for telco company, I wish to develop an app to narrow done
> issues experience by the customer
> The app is not for market, it just for internal used
>
> I already post question is stackoverflow, but nobody response to it yet..
> http://stackoverflow.com/questions/16343164/android-how-to-get-call-dropped-again-com-android-internal-telephony-conne
>

As part of the effort to get a DTMF sending API into Android, we at
MattaKis Consulting implemented a more detailed Phone state change
API. You can check out the patches here (submitted by one of my
developers):
https://android-review.googlesource.com/#/c/32820/
https://android-review.googlesource.com/#/c/32821/
https://android-review.googlesource.com/#/c/32810/

Unfortunately these patches are against ICS and not JB. We have a
work-in-progress update of these patches internally for JB, but
unfortunately other projects became higher priority, and we never got
around to finish the patches and submit them to AOSP.

If installing a custom AOSP or e.g. CyanogenMod build on your devices
is acceptable, then it is possible to get what you want by following
the path shown in our patches. We would be also happy to work with you
on this project, if you need any help.

Best Regards,
Gergely

--
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

[Wink Saville]

Needs to be in JB

--

---
You received this message because you are subscribed to the Google Groups "Android Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-contr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Gergely Kis]

Dear Wink,

I just saw your answer, it is great to have a member of the Telephony
team in the discussion.

Are you referring to the DisconnectCause, or that if we update our
DTMF patches for the current master (or more specifically the master
version after Android 4.3 is released, because the tree is probably
already in feature-freeze), then your team would consider including
it?

There are already a lot of developers and users waiting for this DTMF
sending feature according to this issue:
https://code.google.com/p/android/issues/detail?id=1428

Regarding accessing the DisconnectCause: would the Telephony team be
open to include it also as a public interface, e.g. as part of the
PhoneStateListener?

If you don't want to add these features into the SDK just yet, one
possibility would be to create a private interface that is hidden from
the SDK, so you are not bound to maintain API compatibility across
releases, but is still accessible to those, who would like to use it.
For DTMF sending one such place would be the ITelephony service
interface, which can be accessed, if someone needs it, but is not part
of the SDK API.

A similar place could be found for the API to access the DisconnectCause codes.

Thank you,
Gergely


2013/5/11 Wink Saville <wi...@google.com>:

[Roger Madsen]

I have a concern about possible issues if this api is used by several apps at the same time. How do you make sure that start and stop request from different callers at the same time done interfere?

/Roger

[Gergely Kis]

Hi Roger,

Thank you for taking the time to look at our patches.

One of the reasons for introducing the address parameter on each of
the API calls was to prevent such accidental interference: the
application has to know the endpoint address before calling a DTMF API

This is of course no protection against actively malicious (or just
really dumb) apps, but those could do a lot of other things, like
dropping calls while you speak, dialing numbers you didn't want ...
etc.

On the other hand, it does prevent malicious apps from tricking you
into giving your telebank password to a phishing app, if they somehow
managed to place a call to a different number without you noticing.

We considered creating a session oriented Call API, where ẹ.g. an
application could be the owner of a Call, and only that app (and the
system phone app) could control it, like send dtmf, put it on hold, or
hang up. However, we thought that it would be simpler to first get
this stateless API into the platform, and if there is sufficient
interest (mostly from the Google side :) ), we could work on a
stateful Call API.

Of course we are open to any suggestion, so please feel free to point
out any issues with our approach.

Best Regards,
Gergely

2013/6/20 Roger Madsen <roger....@sonymobile.com>:

[b_a...@hotmail.com]

Hi Fabrício,

Did you get more info? because I have the same problem and I need this information please.

Thanks in advance,

BA

On Thursday, January 24, 2013 11:57:16 PM UTC+1, Fabrício Silva wrote:

Hi Roger, how are you?

  Could you please provide more information (maybe a code snippet) of how to get the disconnect cause from an Android telephony?

  I've started working on a similar problem and could not found any relevant information about that.

Thanks in advance

Regards

Fabrício Silva