Comment 1 Andre Klapper 2010-02-04 21:15:22 UTC

Thanks for reporting this.
You mention *# in the summary, but #21# in the steps to reproduce.

Anyway, this particular bug has already been reported into our bug tracking
system, but please feel free to report any further bugs you find. Also feel
encouraged to vote for the original bug report if interested.
Please feel free to search for existing tickets first to avoid filing
duplicates.


*** This bug has been marked as a duplicate of bug 5357 ***

This bug is about 3GPP TS 22.030 compliance and not about USSD.
(#21# is not USSD)

It defines * AND # and combinations.
The example is relevant or do you prefer a list of all 22.030 violations  ?
(you can add **21*112# if that helps)

Could you point me to the spec what is relavant for closing a ticket here ?
Summary, Problem, Comments ?

(In reply to comment #2)
> Could you point me to the spec what is relavant for closing a ticket here ?
> Summary, Problem, Comments ?
> 

Relevant information here is the internal Nokia process for bug lifecycle. It
can be found somewhere on the site, but in short, the bit relevant here is that
the issue has been fixed and verified *internally*. It will then become
publicly available in a software update which includes the fix. Bug Andre
pointed to mentions the internal release (year.week-N) with the fix. The first
public software update later than that will have the fix. We just have to wait
for it...

HTH

Comment 4 Andre Klapper 2010-02-11 18:29:44 UTC

So for the upcoming PR1.2 release Nokia implemented most of the stuff from TS
22.030, but officially Nokia does not support them. I.e. the UI displays an
error when you try to send something that's not supported.

Hence closing as WORKSFORME.

(In reply to comment #4)

EXACT STEPS LEADING TO PROBLEM: 
1.) Open Phone
2.) Dial #21#
3.) Press Call

#21# is confirmed to _not_ work.

> 
> Hence closing as WORKSFORME.
>

Comment 6 Naba Kumar 2010-05-27 17:15:29 UTC

Hi Trapp,

I think it's more useful to file bugs for the relevant "features" you as a user
miss in the phone. For exmaple, what does "#21#" do for you? Can you not do the
function with N900?

"3GPP compliance" is a concern for Nokia, not for users (unless, you are an
operator or something, which I gather you are not). So this bug is not useful
in any sense.

As a user, please stay focused on your desire to have specific features or
functional bugs. Then it's easier to vote, hence prioritize, which ones are
more important or useful.

Comment 7 Graham Cobb 2010-05-27 18:17:02 UTC

(In reply to comment #6)
> I think it's more useful to file bugs for the relevant "features" you as a user
> miss in the phone. For exmaple, what does "#21#" do for you? Can you not do the
> function with N900?

I disagree.  My functional need is to be able to use the set of "contacts" I
have defined and used with all my previous phones that do various things. 
Primarily those are controlling forwarding, in various different ways, each
with a single button press.  

For example, I have always had a contact called "->Home" defined, on every
phone I have owned, to forward the phone to my home (I live in an area with
poor coverage).  I have set that to speedial #4 on every phone which supports
speeddials.  And I have set it up as a contact on the home screen on every
phone which supports that concept.  So, a single touch forwards the phone for
me.

The SS codes are defined in order to allow users to use network services in a
standardised way, across multiple devices.  The fact that each phone ALSO
offers a non-standard way of using the feature does not mean it should prevent
users using the standardised method.  The standard was created for a reason and
the N900 team do NOT know better than the 3GPP.

So, I am not asking for features or settings to correspond to the individual SS
codes.  I am asking for a complete implementation of the standard.  As a
long-suffering user, if I had my way, no phone would get type approval if it
did not comply.

Comment 8 Naba Kumar 2010-05-27 20:01:55 UTC

Repeating Lassi's comment from bug
https://bugs.maemo.org/show_bug.cgi?id=5357#c178

(In reply to comment #178)
> (In reply to comment #168)
> > If you are *still* interested to play with SS codes "dialing" via Dialer
> > (despite the User-Interface), there is an ester egg available to enable it in
> > PR1.2. You have to work it out yourself or tip Lassi with some beers before he
> > reveals it :).
> 
> The following lines in ~/.osso/call-ui.ini do the trick:
> [supplementary]
> ssc=1
> 
> Please note that officially this feature does not exist and therefore does not
> come with a warranty of any kind. The settings applet (Settings > Phone) does
> not properly indicate some of the services and does not allow revoking all of
> them. Only modify the .ini file if you are feeling experimental and already
> know your way around the MMI codes.
> 

Replying to Cobb from https://bugs.maemo.org/show_bug.cgi?id=5357#c177

(In reply to comment #177)
> 
> > Sounds like this is what you are after:
> > http://maemo.org/downloads/product/Maemo5/callforwarding/
> 
> No, I know that app well and use it heavily -- I wrote a similar, earlier app
> which I dropped when this one came along as its GUI is better. I have been in
> communication with its author, and I plan (one day) to extend it to provide
> some additional features such as profiles (which combine multiple settings) and
> automatic changes ("always forward to home when my location is within 100m of
> my house", etc.).
> 
> None of that replaces the use of SS.  Particularly for things other than
> forwarding!
> 
> Let's take the discussion to bug #8830, which is the bug report for the SS code
> bug.
> 

Hi Cobb, you seem like a perfect candidate to help yourself and others that are
in similar situation. If you follow Lassi's ester egg, all that's needed is a
simple deb package to script it in. Can you do this small favour? You can put
it up in maemo-extras and get some fame bonus too.

(In reply to comment #8) 
> Hi Cobb, you seem like a perfect candidate to help yourself and others that are
> in similar situation. If you follow Lassi's ester egg, all that's needed is a
> simple deb package to script it in. Can you do this small favour? You can put
> it up in maemo-extras and get some fame bonus too.
> 

Naba, you are not doing Nokia image any favours. 

It is one thing to say "we will not implement X, because we firmly believe in
Y". It is entirely a different thing to tell users off for wanting something
they're used to - including on other Nokia phones. It is of course highly
preferable that "Y" be a compelling reason.

Comment 10 Naba Kumar 2010-05-27 23:35:40 UTC

(In reply to comment #9)
> 
> Naba, you are not doing Nokia image any favours. 
> 
> It is one thing to say "we will not implement X, because we firmly believe in
> Y". It is entirely a different thing to tell users off for wanting something
> they're used to - including on other Nokia phones.

Hi Valdamir, I did not do any of that sort. If you read my comment, I brought
the little change needed to enable SS codes from the other bug. What is left is
just to enable it. and since Graham Cobb is demonstrably been wring maemo
software and interested in using it, it should be quite trival for him and
upload to maemo for other. That's why I asked him.

> It is of course highly preferable that "Y" be a compelling reason.
> 
The reason it's not enabled in official release is complicated and not
typically worth discussing here. What matters is that support is there for
anyone to enable. One person doing it all that takes.

Comment 11 Andre Klapper 2010-06-01 19:25:38 UTC

*** Bug 10478 has been marked as a duplicate of this bug. ***

After I have made the addition in the file call-ui.ini, I can now use the
following codes on my N900

- #21# -> cancel a divert all
- *21*0032486191933# -> activate a divert all
- *61*0032486191933**30# -> activate a divert if no reply after 30secs

Thx

Just tried to suppress number with "#31#NUMBER"... not working any *# gsm code
isnt working for me atm, and codes that seem to work (loading screen) tell that
it's request not completed. So nothing but version and imei codes work for me.
Most of the widely known codes are either "Service code not supported" or do
not complete.
This is pr1.2 now, pls change.

sry to wake this up again, overread the ssc part

I have just spent 30 mins on the phone to Orange Support trying to get a call
diversion problem resolved that I could easily have sorted out myself if
service codes were supported.

Somehow (and this actually could not have happened but it did!) my phone was
diverting *all* calls to my backup phone. 

I did not set this to happen and in "settings/phone" call forwarding was set to
"no". I do have shortcuts to divert calls to my backup phone in my contact list
(left over from previous, standards compliant, phones) but of course, they
don't work on the N900. So that can't have been what made it happen.

Comments such as this:

(In reply to comment #6)

> I think it's more useful to file bugs for the relevant "features" you as a user
> miss in the phone. For exmaple, what does "#21#" do for you? Can you not do the
> function with N900?
> 
> "3GPP compliance" is a concern for Nokia, not for users (unless, you are an
> operator or something, which I gather you are not). So this bug is not useful
> in any sense.
> 
> As a user, please stay focused on your desire to have specific features or
> functional bugs. Then it's easier to vote, hence prioritize, which ones are
> more important or useful.
> 

Come across to me as patronising and antagonistic - certainly unhelpful. I am
used to phones that support standard operations and I was extremely surprised
that the N900 doesn't. 

In my view this is definitely a bug and should be addressed as such.

Rgrds

Peter T

I agree. We are talking about basic phone functions needed for a basic phone
use.
Regards.

let me quote from TS22.030:

6.5.1 General
The supplementary services SHALL be controlled in accordance with the
procedures described below. All User Equipment with MMI SHALL be able to be
controlled in this way, to minimize the confusion of users using different
types of User
Equipment (quite likely, due to the use of the SIM IC card) and to permit the
introduction by a PLMN operator of new supplementary services,
*_not_defined_at_the_time_of_the_design_* of a User Equipment. These procedures
are based on those recommended by ETSI/HF and ITU-T Recommendation E.131.

The specified MMI SHALL be supported by the L3 signalling between the UE and
the MSC, see TS 24.080 [10].

In addition to these specified MMI procedures the UE MAY be equipped with
additional enhanced MMI procedures (e.g. dedicated keys, menu procedures...),
left to the discretion of the manufacturer. These procedures SHALL also be
converted in accordance with TS 24.080 [10].
</quote>



I don't think these are optional functions to any User Equipment that has the
capability to enter numbers and to place GSM calls.They are *mandatory*. If I
buy a GSM device I may expect it is designed in accordance to these specs.

Please fix that FOR GOOD. Finally! Still completely broken in PR1.2. It's NOT
ACCEPTABLE N900 is missing functions every(!) 20$ phone is providing, according
to the specs by 3GPP. It's also not acceptable Nokia claims "not supported", as
the device has GSM cert (I wonder how they passed that, or did they at all?)

Comment 18 Naba Kumar 2010-07-22 11:15:57 UTC

Hello everyone. Now you can easily enable SS codes support by installing
"Starhash Enabler" application from your N900 Application Manager. Thanks to
Joerg and Lassi and others who create it. This is as far as it can be
officially fixed, so I am resolving the bug fixed.

You can read about the app at
http://maemo.org/packages/package_instance/view/fremantle_extras-devel_free_armel/starhash-enabler/0.1/
also, but it's simpler to just install from Application Manager.

Comment 19 Andre Klapper 2010-07-22 11:23:09 UTC

Errm, well...
Before people try "Starhash Enabler", please DO read
http://wiki.maemo.org/Extras-devel first.

EXACT STEPS LEADING TO PROBLEM: 
1.) Open Phone
2.) Dial *21**16#
3.) Press Call

EXPECTED OUTCOME:
1.) SMS's are diverted to "parallell" SIM card
2.) Confirmation from the network that 1.) was successful

ACTUAL OUTCOME:
Banner: "Operation not compatible with current status" 
SMS's not diverted 

Cancelling a divert  #21**16# gives same error banner, but checking status 
*#21**16# works fine (and returns correct banner)

Comment 21 Andre Klapper 2010-08-09 10:40:14 UTC

(In reply to comment #20)
> *#21**16# works fine (and returns correct banner)

...and that's what this report is about.
Thanks for the confirmation that it works.

(In reply to comment #21)
> (In reply to comment #20)
> > *#21**16# works fine (and returns correct banner)
> 
> ...and that's what this report is about.
> Thanks for the confirmation that it works.
> 

Sorry, I should have mentioned that I have "Starhash Enabler" installed.

(In reply to comment #20)
> EXACT STEPS LEADING TO PROBLEM: 
> 2.) Dial *21**16#

> ACTUAL OUTCOME:
> Banner: "Operation not compatible with current status" 
> SMS's not diverted 
> 
> Cancelling a divert  #21**16# gives same error banner, but checking status 
> *#21**16# works fine (and returns correct banner)

the message  "Operation not compatible with current status" sounds like a reply
of network rather than rtcom-call-ui or cellmo refusing to deal with the SSC
correctly. 

Have you tried
**21*<number-of-alternate-SIM>*16#
to set up the divert correctly? The *21**16# code you are mentioning is only to
activate an already configured redirect, but to work it usually needs proper
configuration first by sending some code similar to the one I quoted above,
otherwise you'd get exactly this "Operation not compatible..." message from
network, which is correct in that case.

Thanks for the tip, but I believe the divert is correctly setup, same SIM card
worked on my previous phone (and calls work on both phones). Just SMS's don't,
they would need to be diverted by that service code.