Skip to content

Conversation

@alfonsosanchezbeato
Copy link
Contributor

When using dialer to enter CLIR SS codes, the operations in the network were different than those sent when using the call setting interface properties. Works for mako and Krillin.

*31# -> Activates CLIR: no number is shown in called phones
#31# -> Deactivates CLIR: number is shown again in called phones. Calls to #31# should still hide the call in destination.

This is related to https://bugs.launchpad.net/ubuntu/+source/ofono/+bug/1263229

@tonyespy
Copy link
Contributor

A couple of comments / questions...

The bug in question was originally reported against maguro, which since has been deprecated by Ubuntu. Also, the last comment in the bug posits that different device-specific implementations may be required, although I don't see such in this pull-request, as you're proposing a two-line fix to the core ofono call-settings atom. So, please close the referenced bug as Invalid, and create a new bug that describes the problem being fixed by this pull request.

In the bug please explain:

  1. You state that the operations in the network are different when trigged by SS codes than those triggered by CallSetting interface properties. Which properties, and please explain the differerence between SS triggered and settings triggered.
  2. I'm not sure what you mean by "Calls to gril: Set a default value for number of calls #31# should still hide the call in destination"?

When using dialer to enter CLIR SS codes, the operations in the network
were different than those sent when using the call setting interface
properties.
@alfonsosanchezbeato
Copy link
Contributor Author

I think that what bothered me was that I was getting incoherent values for org.ofono.CallSettings properties:

string CallingLineRestriction [readonly]
string HideCallerId [readwrite]

In some cases one was "enabled" and the other "disabled", or the other way around. Unfortunately, I have discovered today that this seems to be operator dependent, so maybe my previous reasoning was wrong. You can access the properties either directly:

dbus-send --system --type=method_call --print-reply --dest=org.ofono /ril_0 org.ofono.CallSettings.SetProperty string:"HideCallerId" variant:string:"disabled"

or using SS codes.

TBH, I need to investigate this further. I do not fully understand the relationship between the two variables and the CLIR behaviour seems operator dependent. I think we can freeze this PR for the moment if you do not mind.

@tonyespy
Copy link
Contributor

tonyespy commented Nov 4, 2014

So I agree with you that we should hold off on this till we have a better understanding of the problem.

Note, regarding CallingLineRestriction & HideCallerId, it's possible for them to differ as 'HideCallerId' can be used to override CallingLineRestriction, per the documentation.

I did some informal testing on mako and krillin this afternoon with an AT&T SIM. Here's what I found.

  1. The SS codes do seem backwards, as *31# causes the subscriber's number to be shown at the remote call when making an outgoing call, and gril: Set a default value for number of calls #31# will restrict the number. This is what I've seen documented online:

http://www.geckobeach.com/cellular/secrets/gsmcodes.php

  1. gril: Set a default value for number of calls #31# seems to work OK on mako with an AT&T SIM, but doesn't appear to work on krillin. I actually managed to get krillin into a state after issuing two "test-ss gril: Set a default value for number of calls #31#" where the device wouldn't make outgoing calls ( dialing a number would hang, and then eventually disconnect with 3 beeps ). I sent a "*31$#" and this condition cleared up.
  2. In neither case did I see a sent SS string result in the CallingLineRestriction property change.

So, sounds like there's still more investigation needed. If / when you manage to do so, please make sure to open one or more bugs and include in the updated pull request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants