Bug 5357 - (int-144051) Does not accept GSM (USSD) Codes starting with *#
(int-144051)
: Does not accept GSM (USSD) Codes starting with *#
Status: CLOSED FIXED
Product: Chat & Call & SMS
Call Application UI
: 5.0/(3.2010.02-8)
: N900 Maemo
: High normal with 189 votes (vote)
: 5.0/(10.2010.19-1)
Assigned To: rtcomm@maemo.org
: call-ui-bugs
:
:
:
: 8428
  Show dependency tree
 
Reported: 2009-10-13 02:44 UTC by Keywan Najafi Tonekaboni
Modified: 2015-05-15 09:55 UTC (History)
94 users (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description Keywan Najafi Tonekaboni (reporter) 2009-10-13 02:44:10 UTC
SOFTWARE VERSION:
1.2009.41-10

STEPS TO REPRODUCE THE PROBLEM:
1. Open Phone to make a call.
2. Type *100# as number to check prepaid credit (most Providers in Germany
support this) or any other GSM code
3. Click on Call-button

EXPECTED OUTCOME:
GSM Code will be send and a answer from the network will be received and shown
on the display

ACTUAL OUTCOME:
An error appear immediately: "Incorrect Number". Because the response is so
fast its obvious that the GSM code was never send

REPRODUCIBILITY:
always

EXTRA SOFTWARE INSTALLED:
irrelevant 

OTHER COMMENTS:

This GSM codes are a basic feature of a GSM phone. although most mobile phone
users doesn't now about them, they are crucial. It's the only way to check
prepaid balance from foreign countries, ordering special plan options (products
like umts flatrates) and an easy way to charge the prepaid account. Also they
can be used to set call diversions
Comment 1 Lucas Maneos 2009-10-13 03:46:28 UTC
Confirming, it seems that anything starting with "*" is rejected by the UI. 
Also resetting severity and priority to defaults.
Comment 2 Keywan Najafi Tonekaboni (reporter) 2009-10-13 03:54:23 UTC
(In reply to comment #1)
> Confirming, it seems that anything starting with "*" is rejected by the UI. 

also # in the beginning isn't accepted. I think what a good and what a bad
number is should be decided by the network, not the phone..

> Also resetting severity and priority to defaults.
sorry for changing them. I just read the howto and won't touch them in the
future so unthought again
Comment 3 Lucas Maneos 2009-10-13 16:42:03 UTC
*** Bug 5380 has been marked as a duplicate of this bug. ***
Comment 4 Lucas Maneos 2009-10-13 16:46:18 UTC
Destinations starting with * or # are accepted by the UI for SIP and XMPP cals.
Comment 5 Lucas Maneos 2009-10-13 17:07:19 UTC
*** Bug 5380 has been marked as a duplicate of this bug. ***
Comment 6 Andre Klapper maemo.org 2009-10-13 20:57:40 UTC
Heh, I had a bet three weeks ago that this will get 20 dups....

*# codes were never defined as a requirement for this release.
According to the internal ticket this is planned for later on.

Feel free to vote.
Comment 7 Keywan Najafi Tonekaboni (reporter) 2009-10-13 23:27:23 UTC
why is this seen as an enhancement and not a bug? 
It's not a rhetorical question, I am curios why other people consider this as
not important.
Comment 8 Valério Valério maemo.org 2009-10-14 00:41:11 UTC
(In reply to comment #7)
> why is this seen as an enhancement and not a bug? 
> It's not a rhetorical question, I am curios why other people consider this as
> not important. 
> 

As a example, in some cheap carriers in Portugal, the only way to consult the
remaining credit is through these codes. I bet this happens in other carriers
at least in Europe
Comment 9 Lucas Maneos 2009-10-14 11:15:59 UTC
(In reply to comment #7)
> why is this seen as an enhancement and not a bug? 

Mainly since:

(comment #6)
> *# codes were never defined as a requirement for this release.

Doesn't mean this isn't an important omission, and votes can help illustrate
that.
Comment 10 Lucas Maneos 2009-10-17 22:19:42 UTC
*** Bug 5547 has been marked as a duplicate of this bug. ***
Comment 11 Lucas Maneos 2009-10-21 10:54:42 UTC
*** Bug 5644 has been marked as a duplicate of this bug. ***
Comment 12 Andre Klapper maemo.org 2009-11-05 18:05:05 UTC
*** Bug 6044 has been marked as a duplicate of this bug. ***
Comment 13 Lucas Maneos 2009-11-08 12:20:37 UTC
*** Bug 6084 has been marked as a duplicate of this bug. ***
Comment 14 Naba Kumar nokia 2009-11-14 01:29:52 UTC
We are aware of missing USSD support, we plan to do it in some release update.
Comment 15 Yves DESSERTINE 2009-11-24 22:17:34 UTC
IMHO it would be nice to add this feature to this flagship device. USSD is part
of the GSM standard:

Quote from
http://en.wikipedia.org/wiki/Unstructured_Supplementary_Service_Data:
================================================================================
USSD Phase 1, specified in GSM 02.90, only supports mobile initiated operation
(pull operation). In the core network the message is delivered over MAP. USSD
Phase 2, specified in GSM 03.90, supports network-initiated operation (pulls
and push operation).
================================================================================

Yves DESSERTINE
Comment 16 Edgardo Calabrese 2009-11-26 13:00:39 UTC
I think that this should be treated as a major bug, because "#" is often used,
for essential operations.

Eg: in italy the bis service, from vodafone (twin SIMs) is managed via SAT or
via USSD string.

SAT is absent USSD doesn't works, so is essential to fix this bug.
Comment 17 Alexander Bokovoy 2009-11-27 16:29:45 UTC
Here -- http://juick.com/Unatine/394204 (beware, Russian-only) -- people were
able to get USSD working in 1.2009.42-11 by directly communicating with a
modem:

ATZ
OK
AT+CUSD=1,"*102#",15
+CUSD: 0,"04110430043B0430043D0441003A0020003900310032002E003600320440002E",72

OK

Then
$ echo "04110430043B0430043D0441003A0020003900310032002E003600320440002E" |
echo -n -e $(tr -d '[:space:]' | sed 's/../\\x&/g') | iconv -f UCS-2BE -t UTF8
Баланс: 912.62р.

What it shows that it is possible to run USSD commands on 1.2009.42-11 even
though it is not yet user-friendly. Quite a UNIX way though.
Comment 18 Venomrush 2009-11-28 16:30:57 UTC
PAYG customers in the UK will be unable to quickly check their balance if *# is
not implemented.

For examples the following are used to check balance for PAYG in the UK and
other countries where I travelled to (using their local sim).

*#10#
*#101#
*#100#

For contract customers, they can quickly check their monthly usage, bill date
and recent charges.

I would consider this as a high priority fix.
Comment 19 Mikhail Zabaluev nokia 2009-11-30 13:51:56 UTC
*** Bug 6454 has been marked as a duplicate of this bug. ***
Comment 20 Andre Klapper maemo.org 2009-11-30 15:02:28 UTC
*** Bug 6439 has been marked as a duplicate of this bug. ***
Comment 21 hex 2009-12-02 09:24:03 UTC
Major issue in US w/T-Mobile as well. How to set, change, activate, deactivate
conditional call forwarding and many other critical functions. This
unquestionably is a major bug that needs to be fixed very quickly. Not allowing
any number regardless of what the device thinks is valid is incomprehensible
and have never seen something like this in any phone.
Comment 22 Vitaly Bordyug 2009-12-02 10:05:30 UTC
(In reply to comment #21)
> Major issue in US w/T-Mobile as well. How to set, change, activate, deactivate
> conditional call forwarding and many other critical functions. This
> unquestionably is a major bug that needs to be fixed very quickly. Not allowing
> any number regardless of what the device thinks is valid is incomprehensible
> and have never seen something like this in any phone.
> 
Conditional call forwarding is able to set up under Settings->Phone IIRC. If
you don't see that right away, scroll it down a little bit. It is not really
flexible, but fits most needs and is better than nothing.
Comment 23 Sergey 2009-12-02 10:08:09 UTC
I confirm, * # does not work.

N900
version 1.2009.42-11
RX-51
Comment 24 hex 2009-12-02 10:37:22 UTC
Sure - appreciate it, but that much I know, but you can't use any other MMI
codes such as check status, change ring time, or set a different number
depending on the condition (well, aside from hassling with putting the SIM into
another phone - not very handy as often as I change these and usually
individually). I also don't like only 20-seconds, which is the other variable I
change to 30. Similar, but different (and hopefully not a 'feature'), but where
is unconditional call forwarding? I use that regularly and if can't be set in
the phone settings, people should be able to do it this way.

I won't bother with the various codes I use periodically, but this was simply
one I discovered when I went to check current status, then tried a few other
MMI codes.

Not to mention how much quicker it is.

I apologize, I know this is a bit venty as was my posting, but I'm already
being very patient for some updates and adds to a pretty bare featured device
that I expected a bit more out of and this issue is as basic, 101 as you get
with a GSM device.
Comment 25 Naba Kumar nokia 2009-12-02 13:21:38 UTC
Hi everyone, we know the significance of this feature. It's planned to 
released in an update later. Please have patience; it will be eventually there
:)
Comment 26 Mikhail Zabaluev nokia 2009-12-02 14:08:57 UTC
We got news from our secret underground bunker lab that the implementation is
on its way.
Comment 27 Donn Morrison 2009-12-02 14:14:54 UTC
(In reply to comment #25)
> Hi everyone, we know the significance of this feature. It's planned to 
> released in an update later. Please have patience; it will be eventually there
> :)

Comment #17 mentions a link which includes the following:

dbus-send --system --dest=com.nokia.csd.Call --type=method_call --print-reply
/com/nokia/csd/call com.nokia.csd.Call.CreateWith string:"$1" uint32:0

It is meant to be called from a shell script, so $1 is the number to dial. This
bypasses the interface restriction meaning you can make voice calls to numbers
with *#.

Is there a similar dbus method call that we can use as a temporary workaround
for non-voice calls, i.e. where the phone prints the response on the screen
(balance, etc.)? I am assuming that the response would be instead printed to
the terminal as a result of the dbus-send command.
Comment 28 micky.aldridge 2009-12-02 14:17:40 UTC
Brilliant, thanks.!
Comment 29 Alexander Bokovoy 2009-12-02 14:20:16 UTC
(In reply to comment #27)
> (In reply to comment #25)
> > Hi everyone, we know the significance of this feature. It's planned to 
> > released in an update later. Please have patience; it will be eventually there
> > :)
> 
> Comment #17 mentions a link which includes the following:
> 
> dbus-send --system --dest=com.nokia.csd.Call --type=method_call --print-reply
> /com/nokia/csd/call com.nokia.csd.Call.CreateWith string:"$1" uint32:0
> 
> It is meant to be called from a shell script, so $1 is the number to dial. This
> bypasses the interface restriction meaning you can make voice calls to numbers
> with *#.
No, this script still does not help in initiating calls to *#. This is just a
script to initiate a call.

You'd need to directly communicate with a modem with commands mentioned in
comment #17 to get USSD responses. A person at that link did it with PC
connected to N900 as a modem.
Comment 30 Lassi Syrjälä nokia 2009-12-02 16:11:00 UTC
> No, this script still does not help in initiating calls to *#. This is just a
> script to initiate a call.

Yes, it will make a call request, and the network will tell you the same thing
that the UI already does (Invalid number, number not in use, or similar).
Besides talking directly to the modem, there's no way to set up a USSD session
yet.
Comment 31 Lassi Syrjälä nokia 2009-12-02 16:29:23 UTC
I.e. the UI does not prevent you from calling any valid number but it does
prevent making call requests with SS and USSD codes.

Thus, "Incorrect number" in this case should be interpreted as "Not a callable
number".
Comment 32 Maksim 2009-12-03 22:31:42 UTC
WTF!!!!!!!!!!!!!!
Comment 33 Andre Klapper maemo.org 2009-12-03 23:41:27 UTC
(In reply to comment #32)
> WTF!!!!!!!!!!!!!!

Do not post completely useless comments, otherwise your account will be
disabled.
This is a technical bugtracker, not a forum. Thanks.
Comment 34 Quim Gil nokia 2009-12-07 09:38:41 UTC
This is being handled as a bug by the Fremantle program.
Comment 35 joe 2009-12-07 16:02:07 UTC
(In reply to comment #34)
> This is being handled as a bug by the Fremantle program.
> 

Do you expect it to be taken care of in the next firmware release?

Thank you.
Comment 36 Andre Klapper maemo.org 2009-12-07 16:09:23 UTC
(In reply to comment #35)
> Do you expect it to be taken care of in the next firmware release?

Too early to say.
Also, Nokia does not announce release dates of updates in advance.
Comment 37 ian 2009-12-07 22:38:57 UTC
got the same problem with my n900, is there any solution for this?
Comment 38 Andre Klapper maemo.org 2009-12-07 22:42:00 UTC
(In reply to comment #37)
> got the same problem with my n900, is there any solution for this?

It's all clearly written in this report, but adding more comments makes it
harder to quickly find the useful information of course... ;-)
General info: Bugzilla is not a forum.

Comment 17 provides an extremely hackish solution. No other solution is listed
here. Apart from that, the bug report is still "ASSIGNED" and not "FIXED".
Comment 39 Edgardo Calabrese 2009-12-08 00:59:11 UTC
> Also, Nokia does not announce release dates of updates in advance.


I know that here isn't exactly the right place to discuss this, but I think
that the sealed mouth on firmware release date fits well on a classic OS
development process, but not on a widely open sourced OS like maemo, even if
bits or this OS are still closed.
Comment 40 Andre Klapper maemo.org 2009-12-08 14:07:11 UTC
(In reply to comment #39)
> I know that here isn't exactly the right place to discuss this

Exactly. See bug 5709 and its link instead.
Comment 41 Thorsten Trapp 2009-12-09 01:34:37 UTC
MMI for UE is well defined in 3GPP TS 22.030.
Most recent version to be found here:
http://www.3gpp.org/ftp/Specs/html-info/22030.htm hope that helps.
I was surprised to see Nokia implementing phone capabilities without such basic
functionality. 
Sidenote: On PIN enty the "#" symbol is consequently missing as well, on most
phones you can even press "#" after PIN to proceed ...
Comment 42 Lassi Syrjälä nokia 2009-12-09 09:12:32 UTC
(In reply to comment #41)
> MMI for UE is well defined in 3GPP TS 22.030.
> Most recent version to be found here:
> http://www.3gpp.org/ftp/Specs/html-info/22030.htm hope that helps.

22.030 is about the well-defined supplementary service procedures but most
people here are asking for USSD (which is practically everything that's not
covered by 22.030).

We have already promised USSD support in a later update. Let's see about the
structured codes for forwarding/barring/waiting/interrogating caller id related
settings... There was a bug about these, but I believe it was resolved as
WONTFIX. Feel free to reopen or vote for it, though.

> Sidenote: On PIN enty the "#" symbol is consequently missing as well, on most
> phones you can even press "#" after PIN to proceed ...

Not consequently. Please file that as a separate ticket to Connectivity.
Comment 43 Thorsten Trapp 2009-12-09 19:19:57 UTC
(In reply to comment #42)
> (In reply to comment #41)
> > MMI for UE is well defined in 3GPP TS 22.030.
> > Most recent version to be found here:
> > http://www.3gpp.org/ftp/Specs/html-info/22030.htm hope that helps.
> 
> 22.030 is about the well-defined supplementary service procedures but most
> people here are asking for USSD (which is practically everything that's not
> covered by 22.030).
> 
> We have already promised USSD support in a later update. Let's see about the
> structured codes for forwarding/barring/waiting/interrogating caller id related
> settings... There was a bug about these, but I believe it was resolved as
> WONTFIX. Feel free to reopen or vote for it, though.
> 
> > Sidenote: On PIN enty the "#" symbol is consequently missing as well, on most
> > phones you can even press "#" after PIN to proceed ...
> 
> Not consequently. Please file that as a separate ticket to Connectivity.
> 

Could you point me to the BUG ?

From the name of the bug and the description you can see the misunderstanding
here. You are talking USSD (purely) but in the comment you read "Also they
can be used to set call diversions". 
My wrong assumption here was that we are facing an MMI error in the phone
frontend and further thought that all specs handling the signalling procedures
are implemented. But what you are saying is that you are "only" looking into
USSD and NOT into general implementation of Supplementary Services.
That means YES for USSD, but NO for call divertion or CLIR....
Since all of that starts with *# it will "feel" like an unpredictable outcome
for MMI users. (why does one command work and the other don't).
Anyway, if you can show me the bug # where you are WONTFIX "Supplementary
Services" I will vote there.
Comment 44 Venomrush 2009-12-13 12:48:28 UTC
Think the title is a mislead and should be changed.

*# or * are more like a carrier service commands initiation.
Comment 45 Lucas Maneos 2009-12-15 16:01:52 UTC
*** Bug 6989 has been marked as a duplicate of this bug. ***
Comment 46 Neil MacLeod maemo.org 2009-12-15 19:32:18 UTC
Not sure about "*#" but it seems that any phone number containing a hash (#) is
considered an "incorrect number".

This is a problem for N900 users wishing to sign up with HulloMail[1]

"For example, i had to dial **004*xxxxxxxxxxxxxx# (where x = number) from my
then HTC Hero, to activate the service."

and I've also been informed by a N900 user in Saudi Arabia, this prevents
checking the balance on PAYG SIMs:

"If I wanna check my Balance on one of my PAYG Saudi sims in Saudi, I have to
dial (*142#) and you read on the screen "Sending Request" after which, you get
your balance."

also from the same user in Saudi, another code which isn't accepted:

"The number that all you have kindly been testing out [**21*1431#] is for
switching a certain service on (where if people call you, they hear as if your
phone is switched off, You however will get a notification text stating who
called and what time)

There is of course another code to dial to switch that service off."

None of the above numbers are accepted as valid in 1.2009.42-11.


1. http://www.hullomail.com/gb/hullomail/FAQs-reg.html
Comment 47 Lassi Syrjälä nokia 2009-12-15 21:04:34 UTC
(In reply to comment #46)
> Not sure about "*#" but it seems that any phone number containing a hash (#) is
> considered an "incorrect number".

Numbers ending in a hash are either Unstructured Supplementary Service Data
(USSD) or Supplementary Service (SS) codes, neither of which 1.2009.42-11
supports.

> This is a problem for N900 users wishing to sign up with HulloMail[1]
> 
> "For example, i had to dial **004*xxxxxxxxxxxxxx# (where x = number) from my
> then HTC Hero, to activate the service."

This is an SS code that registers and activates all conditional (no answer,
unreachable, or busy) diverts to the given number. On N900, this type of divert
can be configured from Settings > Phone.

> "If I wanna check my Balance on one of my PAYG Saudi sims in Saudi, I have to
> dial (*142#) and you read on the screen "Sending Request" after which, you get
> your balance."

This is a USSD code, similar to "*100#" from the first comment of this bug.

> also from the same user in Saudi, another code which isn't accepted:
> 
> "The number that all you have kindly been testing out [**21*1431#] is for
> switching a certain service on (where if people call you, they hear as if your
> phone is switched off, You however will get a notification text stating who
> called and what time)

This is an SS code to register an unconditional divert to number 1431.
Comment 48 Grigori Timonen nokia 2009-12-16 09:34:48 UTC
I think it is useless to put just more examples here. This makes technical
discussion much harder to read and track. Please just vote for a bug, this
gives more effort.
Comment 49 Edgardo Calabrese 2009-12-17 02:50:08 UTC
(In reply to comment #48)
> I think it is useless to put just more examples here. This makes technical
> discussion much harder to read and track. Please just vote for a bug, this
> gives more effort.
> 

I don't know if this is considered an useless example, but I just tried
(successfully) to send the special command to swap the master and slave "BIS" 
SIMs (the italian vodafone's twin sim service).

This is normally done via a SAT menu (missing on the n900)

or

via the *101*1# command (refused by the n900 because the '#' character).

So I simply issued the command "atd *101*1# " to the modem's serial port and
the command worked perfectly.

So I'm still convinced that the main problem is just a stupid bug in the UI
that refuses the # symbol.

Fixing this can solve a lot of troubles to the n900 users, although it surely
not fix all the special commands related problems.
Comment 50 Venomrush 2009-12-17 03:06:42 UTC
(In reply to comment #49)

> So I simply issued the command "atd *101*1# " to the modem's serial port and
> the command worked perfectly.
> 

How do you do this?
Comment 51 Edgardo Calabrese 2009-12-17 03:21:25 UTC
(In reply to comment #50)
> (In reply to comment #49)
> 
> > So I simply issued the command "atd *101*1# " to the modem's serial port and
> > the command worked perfectly.
> > 
> 
> How do you do this?
> 


I did it from windows with absolute telnet, but you can use hypeterminal or any
similar program, or minicom/xminicom if you are using a linux box.

 I think that the same can obtained directly on the n900 if a working version
of minicom is available for the armel architecture.
Comment 52 Lassi Syrjälä nokia 2009-12-17 09:13:32 UTC
(In reply to comment #49)
> This is normally done via a SAT menu (missing on the n900)

Is it not done via the SAT menu because no GSM phone lets you /dial/ "*101*1#"?
If they do, they would have to have special handling for this particular
command, since by the spec, the command should be sent as a USSD, which might
or might not have the same effect.

> So I'm still convinced that the main problem is just a stupid bug in the UI
> that refuses the # symbol.

The UI is aware of supplementary service commands, but unfortunately it cannot
handle them yet and the rather generic banner fails to convey this clearly. As
a curiosity, dialing "*101*1p#" should succeed though I don't expect it to be
handled the same as "ATD *101*1"...
Comment 53 Vladimir Oka 2009-12-17 09:51:32 UTC
(In reply to comment #52)
> The UI is aware of supplementary service commands, but unfortunately it cannot
> handle them yet and the rather generic banner fails to convey this clearly. As
> a curiosity, dialing "*101*1p#" should succeed though I don't expect it to be
> handled the same as "ATD *101*1"...

Interestingly, nobody pointed out that the standard command to get your IMEI
does not work either. The correct behaviour for this is to type in "*#06#" and
as soon as you hit the last "#" the UE should spit out your IMEI. This has
nothing to do with dialling and the modem, and is handled (mostly) only by the
UI. This, to me, suggests that the issue here is probably really in the UI
handling of "#" and a terminating one at that. Otherwise, what I just described
is a separate bug, to do with "N900 unable to reports its IMEI via *#06#
command". I will leave it to the developers to decide if a new bug is needed.
I'll monitor the discussion here for a while and raise a new bug if I don't see
anyone commenting it is the same issue as discussed here (i.e. SS commands).

BTW, the standard Nokia sequence for getting the UE SW version does not seem to
work either. Not listing it here in case it's not supposed to be public
knowledge (even if I know it already is). ;)
Comment 54 Donn Morrison 2009-12-17 10:00:38 UTC
(In reply to comment #51)
>  I think that the same can obtained directly on the n900 if a working version
> of minicom is available for the armel architecture.

Does anyone know the entry under /dev for the modem on the n900?
Comment 55 Mikhail Zabaluev nokia 2009-12-17 11:24:47 UTC
(In reply to comment #53)
> Otherwise, what I just described
> is a separate bug, to do with "N900 unable to reports its IMEI via *#06#
> command". I will leave it to the developers to decide if a new bug is needed.

Isn't "Settings -> About" a more user-friendly way to look up the same?
Comment 56 Vladimir Oka 2009-12-17 11:34:32 UTC
(In reply to comment #55)
> (In reply to comment #53)
> > Otherwise, what I just described
> > is a separate bug, to do with "N900 unable to reports its IMEI via *#06#
> > command". I will leave it to the developers to decide if a new bug is needed.
> 
> Isn't "Settings -> About" a more user-friendly way to look up the same?
> 

Cool. Now just to fix the SS codes... Theres a lot of NWs using them.
Comment 57 Venomrush 2009-12-17 11:42:54 UTC
(In reply to comment #55)

> Isn't "Settings -> About" a more user-friendly way to look up the same?
> 

It's much longer steps and keys to press.
Comment 58 Vladimir Oka 2009-12-17 11:45:12 UTC
(In reply to comment #57)
> (In reply to comment #55)
> 
> > Isn't "Settings -> About" a more user-friendly way to look up the same?
> > 
> 
> It's much longer steps and keys to press.
> 

I still agree with Mikhail. You need this so rarely, that it's not worth
providing a second way of doing the same thing. It's all trade-offs in SW
engineering. I'd rather have the SS codes fixed sooner and type a few extra
keys 
 to get to the SW version and IMEI.
Comment 59 Thorsten Trapp 2009-12-17 11:49:55 UTC
isn't this discussion going into that direction ?:
https://bugs.maemo.org/show_bug.cgi?id=5380


(In reply to comment #58)
> (In reply to comment #57)
> > (In reply to comment #55)
> > 
> > > Isn't "Settings -> About" a more user-friendly way to look up the same?
> > > 
> > 
> > It's much longer steps and keys to press.
> > 
> 
> I still agree with Mikhail. You need this so rarely, that it's not worth
> providing a second way of doing the same thing. It's all trade-offs in SW
> engineering. I'd rather have the SS codes fixed sooner and type a few extra
> keys 
>  to get to the SW version and IMEI.
>
Comment 60 Vladimir Oka 2009-12-17 13:15:02 UTC
(In reply to comment #59)
> isn't this discussion going into that direction ?:
> https://bugs.maemo.org/show_bug.cgi?id=5380
> 

IMO the two are duplicates. Which one is kept open is a different issue. I
would go for 5380 for the better title, but this one has had more discussion so
far. 

OTOH, do we need all this discussion when the issue is clearly that none of the
3GPP SS commands can be issued on N900?
Comment 61 Lassi Syrjälä nokia 2009-12-17 16:09:58 UTC
*#06# for IMEI and *#0000# for SW version are something for the UI to handle.
They will be supported in a forthcoming release as well.
Comment 62 Edgardo Calabrese 2009-12-17 17:32:38 UTC
(In reply to comment #52)
> (In reply to comment #49)
> > This is normally done via a SAT menu (missing on the n900)
> 
> Is it not done via the SAT menu because no GSM phone lets you /dial/ "*101*1#"?

Sorry but I cant understand your point.

Any phone is able to manage that code, with the exception of n900, and some
phones from the jurassic era...

Any phone I tried in the last 5 years is able to manage  both, the SAT menu
with the SIM applications *and* the special codes as *101*1# .

Any phone, even a cheap Nokia 1100


> 
> > So I'm still convinced that the main problem is just a stupid bug in the UI
> > that refuses the # symbol.
> 
> The UI is aware of supplementary service commands, but unfortunately it cannot
> handle them yet and the rather generic banner fails to convey this clearly. As
> a curiosity, dialing "*101*1p#" should succeed though I don't expect it to be
> handled the same as "ATD *101*1"...
> 

Indeed the string *101*1p# is accepted from the phone (p is accepted as a
capital) and treated as a normal call, as you guessed it has no effect on the
service management (the sim aren't swapped).

If I send the same string via the com port, the phone returns "ERROR".


BTW I'm just curios...  

Why "# > send key" and "* > send key" are treated differently by the UI? 



P.S. Just to point to a potential additional problem, what happen if one locks
the SIM entering 3 times the wrong PIN code ?

The PUK unlock code will be accepted ? I bet it doesn't (I haven't tried yet)
Comment 63 Alexander Bokovoy 2009-12-17 20:44:29 UTC
As it was stated several times, please do not use bugzilla for forum-like
discussion, please use talk.maemo.org for that. The issue filed as this bug
(#5357) is under active work by several Maemo development teams already. As
Lassi and others noted, fixes will be introduced in upcoming software updates.
Comment 64 Edgardo Calabrese 2009-12-18 02:23:59 UTC
(In reply to comment #63)
> As it was stated several times, please do not use bugzilla for forum-like
> discussion, please use talk.maemo.org for that. The issue filed as this bug
> (#5357) is under active work by several Maemo development teams already. As
> Lassi and others noted, fixes will be introduced in upcoming software updates.
> 

???

I think that your message is a forum like one, if you think that others
opinions/findings/etc are unuseful just skip them, no one force you to read the
message you don't like.
Comment 65 Lassi Syrjälä nokia 2009-12-18 09:32:37 UTC
(In reply to comment #62)
> Any phone I tried in the last 5 years is able to manage  both, the SAT menu
> with the SIM applications *and* the special codes as *101*1# .

They should send it as a USSD request, which the N900 will do as well. ATD to
me sounds like a command one dials a call with, but perhaps the modem can
handle USSD with it, too? The UI in any case does not interface with the modem
via AT commands...

> The PUK unlock code will be accepted ? I bet it doesn't (I haven't tried yet)

No but there's a UI for that.
Comment 66 Mikhail Zabaluev nokia 2009-12-18 10:43:19 UTC
(In reply to comment #64)
> I think that your message is a forum like one, if you think that others
> opinions/findings/etc are unuseful just skip them, no one force you to read the
> message you don't like.

This is the bug tracker, with mail notifications going to developers who have
many things to work on. Please keep the discussion to necessary technical
details. Refusal to do so may result in termination of your account. We hope
for your understanding.
Comment 67 Pti-seb 2009-12-20 22:50:27 UTC
Same issue in France with this phone number : #123#
It's used to see your consumation with the Orange provider.
Comment 68 Enmanuel Rivera 2009-12-23 21:23:22 UTC
At the moment I am using the phone with Orange Dominican Republic on a a
pre-paid plan. It is IMPOSSIBLE for me to recharge the account. I CANNOT make
phone calls (credit balance is zero), and will soon lose the ability for me to
receive them once the current credit expires.

I need a work around (some kind of script to invoke the modem directly maybe)
in the mean time. Can anyone help?
Comment 69 Vitaly Bordyug 2009-12-23 23:43:20 UTC
(In reply to comment #68)
> At the moment I am using the phone with Orange Dominican Republic on a a
> pre-paid plan. It is IMPOSSIBLE for me to recharge the account. I CANNOT make
> phone calls (credit balance is zero), and will soon lose the ability for me to
> receive them once the current credit expires.
> 
> I need a work around (some kind of script to invoke the modem directly maybe)
> in the mean time. Can anyone help?
> 

The only workaround yet is described in thread here. Attach the phone via cable
in PC Suite mode, and use terminal program (minicom/hyperterminal/etc) to issue
AT commands.
Comment 70 Michał Bartoszkiewicz 2009-12-23 23:47:43 UTC
(In reply to comment #69)
> (In reply to comment #68)
> > At the moment I am using the phone with Orange Dominican Republic on a a
> > pre-paid plan. It is IMPOSSIBLE for me to recharge the account. I CANNOT make
> > phone calls (credit balance is zero), and will soon lose the ability for me to
> > receive them once the current credit expires.
> > 
> > I need a work around (some kind of script to invoke the modem directly maybe)
> > in the mean time. Can anyone help?
> > 
> 
> The only workaround yet is described in thread here. Attach the phone via cable
> in PC Suite mode, and use terminal program (minicom/hyperterminal/etc) to issue
> AT commands.

You can also open the X Terminal, execute sudo gainroot (it requires rootsh to
be installed), then execute pnatd and enter AT commands.
Comment 71 Vitaly Bordyug 2009-12-24 00:12:40 UTC
with n900, I just use 'root' command to become root.

so, the script
Nokia-N900-41-10:~# cat bal.sh 
#!/bin/sh
echo "$1" | echo -n -e $(tr -d '[:space:]' | sed 's/../\\x&/g') | iconv -f
UCS-2BE -t UTF8

and usage

Nokia-N900-41-10:~# bal.sh
04110430043B0430043D0441003A00200034003700390034002E00390440002E002000440065007000650063006800650020004D006F0064006500210020041D043004310435044004380020002A003200380032002300200028003500200440044304310029
Баланс: 4794.9р. Depeche Mode! Набери *282# (5 руб)Nokia-N900-41-10:~#


The magic sequence extracted in dialog with pnatd:

Nokia-N900-41-10:~# pnatd 
AT
OK
AT+CUSD=1,"*100#",15
+CUSD:
0,"04110430043B0430043D0441003A00200034003700390034002E00390440002E002000440065007000650063006800650020004D006F0064006500210020041D043004310435044004380020002A003200380032002300200028003500200440044304310029",72
Comment 72 Venomrush 2009-12-24 02:21:45 UTC
(In reply to comment #68)
> At the moment I am using the phone with Orange Dominican Republic on a a
> pre-paid plan. It is IMPOSSIBLE for me to recharge the account. I CANNOT make
> phone calls (credit balance is zero), and will soon lose the ability for me to
> receive them once the current credit expires.
> 
> I need a work around (some kind of script to invoke the modem directly maybe)
> in the mean time. Can anyone help?
> 

Well, there's a very simple solution to that. Take the sim card out and put it
in your old phone and do the top-up for credits.

Btw, this still has not been fixed in PR1.1? 
A little disappointed if it isn't which means we'll have to wait at least until
February for the fix.
Comment 73 Alexander Pevnitsky 2009-12-24 08:53:57 UTC
This bug is very strange in mobile (with phone) device! )
Comment 74 Tomasz Dominikowski 2009-12-24 12:07:24 UTC
*#0000# and *#06# work fine in PR1.1. Is this the only scope of the bug? If
yes, this can be VERIFIED FIXED.
Comment 75 Uwe Kaminski 2009-12-26 01:44:05 UTC
This bug is about the UI which was blocking the input of * an #. This is solved
in the PR 1.1 Firmware and so the bug indeed is verified fixed.
Comment 76 Lassi Syrjälä nokia 2009-12-26 10:39:38 UTC
There are various kinds of MMI codes which the UI needs to recognize, parse,
and handle accordingly:

1) SS procedures (e.g. *43# to activate call waiting)
2) SIM control procedures (e.g. **04*...# to change the PIN code)
3) IMEI presentation procedure (*#06#)
4) Manufacturer-defined procedures (e.g. *#0000#)
5) USSD commands (operator-defined, e.g. *100# to check prepaid credit)

In 1.2009.42-11, anything that fell into these categories was rejected as
"Incorrect number" (which is less shameful than requesting a call be set up).
PR1.1 adds *#06# and *#0000# from categories 3 and 4 but retains the old
behavior for the rest. Categories 1 and 2 are to an extent configurable from
the settings UI but for the 5th one (that this bug is about), there's
unfortunately no support in the PR1.1 (pre-)release either.

This has already been addressed internally, though, so resolved/fixed is a
truthful resolution in any case...
Comment 77 Venomrush 2009-12-26 11:14:13 UTC
(In reply to comment #76)

> This has already been addressed internally, though, so resolved/fixed is a
> truthful resolution in any case...
> 

Truthfully the initial bug report was for handling *100# USSD commands so this
should not consider as fixed.

Marking this as fixed will throw out 3 new separate bug reports for each of the
following categories:

1) SS procedures (e.g. *43# to activate call waiting)
2) SIM control procedures (e.g. **04*...# to change the PIN code)
5) USSD commands (operator-defined, e.g. *100# to check prepaid credit)
Comment 78 Lassi Syrjälä nokia 2009-12-26 11:53:50 UTC
(In reply to comment #77)
> Truthfully the initial bug report was for handling *100# USSD commands so this
> should not consider as fixed.

The fix is ready, so it's merely a question of when it can be released to
public. I believe we have usually closed publicly tracked bugs as they are
closed internally, but it's up to you guys if you prefer to keep this open
until the fix hits a public release.
Comment 79 Attila Csipa nokia 2009-12-26 14:45:59 UTC
How deep are the changes in question ? Would it be possible/feasible to
negotiate having the fix (even in source form, with a 1m x 1m Caveat Emptor
sign) attached here ? I'd rather recompile things than wait till ~April for the
next firmware release.
Comment 80 Aniello Del Sorbo 2009-12-26 16:05:27 UTC
This has been verified in my 2.2009.51-1. I tried the IMEI code and it worked.
Comment 81 Ryan Abel maemo.org 2009-12-26 19:59:08 UTC
(In reply to comment #78)
> (In reply to comment #77)
> > Truthfully the initial bug report was for handling *100# USSD commands so this
> > should not consider as fixed.
> 
> The fix is ready, so it's merely a question of when it can be released to
> public. I believe we have usually closed publicly tracked bugs as they are
> closed internally, but it's up to you guys if you prefer to keep this open
> until the fix hits a public release.
> 

Bugs are RESOLVED when the code has been committed, bugs are CLOSED when the
code has been released.
Comment 82 Venomrush 2009-12-26 20:12:45 UTC
(In reply to comment #80)
> This has been verified in my 2.2009.51-1. I tried the IMEI code and it worked.
> 

Verified against initial bug report? (issuing *100# like USSD commands)

Looking up IMEI using *#06# and *#0000# is NOT a fix for this bug report, which
apparently claimed as a fix as a whole in '09.51-1
Comment 83 Lassi Syrjälä nokia 2009-12-27 00:38:57 UTC
(In reply to comment #81)
> Bugs are RESOLVED when the code has been committed, bugs are CLOSED when the
> code has been released.

A resolved bug can be REOPENED, suggesting the bug has entered the first stage
of closure. ;-)

Anyway, the point was that although this bug entered RESOLVED/FIXED state on
seemingly wrong grounds, the state is actually representative of our internal
builds. Verification and final closure must wait until the fix has been
released, obviously.

(As for the possibility of an intermediate release, I am afraid the changes are
too deep. After all, we are talking about a missing feature rather than a
simple bug in the UI)
Comment 84 Andre Klapper maemo.org 2009-12-28 15:27:08 UTC
*** Bug 7360 has been marked as a duplicate of this bug. ***
Comment 85 Andre Klapper maemo.org 2009-12-29 12:33:15 UTC
*** Bug 7412 has been marked as a duplicate of this bug. ***
Comment 86 Andre Klapper maemo.org 2009-12-30 16:28:49 UTC
*** Bug 7492 has been marked as a duplicate of this bug. ***
Comment 87 Lucas Maneos 2010-01-03 06:53:29 UTC
*** Bug 7589 has been marked as a duplicate of this bug. ***
Comment 88 Martin Grimme 2010-01-06 01:24:53 UTC
See http://talk.maemo.org/showpost.php?p=454839&postcount=23 for an
intermediate solution for USSD codes.
Comment 89 Lucas Maneos 2010-01-07 06:23:27 UTC
*** Bug 7721 has been marked as a duplicate of this bug. ***
Comment 90 kimitake 2010-01-11 22:51:39 UTC
I have updated firmware, 2009.44-1.002, but the issue has not been fixed yet.

I have t-mobile USA prepaid SIM, so just tried to call #225# to get
account balance information, but the phone app shows
"Incorrect Number" as before.
Comment 91 Andre Klapper maemo.org 2010-01-11 23:12:12 UTC
This will be included in the "PR1.2" update release it seems. Hence the next
release (called PR1.1) will probably not include this...
Comment 92 max 2010-01-13 21:31:56 UTC
*** Bug 7922 has been marked as a duplicate of this bug. ***
Comment 93 kimitake 2010-01-14 12:53:44 UTC
I have updated firmware, 2.2009.51-1.002, but the issue has not been fixed yet.

I have t-mobile USA prepaid SIM, so just tried to call #225# to get
account balance information, but the phone app shows
"Incorrect Number" as before.
Comment 94 Andre Klapper maemo.org 2010-01-14 12:59:37 UTC
(In reply to comment #93)
> I have updated firmware, 2.2009.51-1.002, but the issue has not been fixed yet.

As already written in comment 91, this is not included in 2.2009.51-1. If it
was, I would have reset the Target Milestone to 2.2009.51-1 anyway already.
Comment 95 Andre Klapper maemo.org 2010-01-14 18:11:02 UTC
*** Bug 7984 has been marked as a duplicate of this bug. ***
Comment 96 Louis Chan 2010-01-14 19:14:35 UTC
Here in Hong Kong. Also need **21*xxxxxx# / ##21# to enable /disable divert
call. Still not working. 

If it's not in this fix, why in resolved fixed?

(In reply to comment #94)
> (In reply to comment #93)
> > I have updated firmware, 2.2009.51-1.002, but the issue has not been fixed yet.
> 
> As already written in comment 91, this is not included in 2.2009.51-1. If it
> was, I would have reset the Target Milestone to 2.2009.51-1 anyway already.
>
Comment 97 Andre Klapper maemo.org 2010-01-14 19:35:49 UTC
(In reply to comment #96)
> If it's not in this fix, why in resolved fixed?

Please read bug reports before adding useless comments - in this case comment
91. Also please do not fullquote the entire former posting without any reason,
please do not answer above the quote, and please read the basic stuff before
adding comments, such as the "Resolution" link which leads to
https://bugs.maemo.org/page.cgi?id=fields.html#resolution .
Comment 98 bigbrovar 2010-01-14 20:26:44 UTC
(In reply to comment #97)
> (In reply to comment #96)
> > If it's not in this fix, why in resolved fixed?
> 
> Please read bug reports before adding useless comments - in this case comment
> 91. Also please do not fullquote the entire former posting without any reason,
> please do not answer above the quote, and please read the basic stuff before
> adding comments, such as the "Resolution" link which leads to
> https://bugs.maemo.org/page.cgi?id=fields.html#resolution .
> 
many of us have been linux users before the n900 and are familier with the way
bugzila works. however there are many who are new to all this. the best
approach is to be polite and repond to comments in a respectful manner. we are
a community and we need to have a level what is not acceptable level of
interaction.
Comment 99 Andre Klapper maemo.org 2010-01-14 20:36:42 UTC
*** Bug 7991 has been marked as a duplicate of this bug. ***
Comment 100 Vladimir Oka 2010-01-14 23:59:42 UTC
(In reply to comment #98)
> (In reply to comment #97)
> > (In reply to comment #96)
> > > If it's not in this fix, why in resolved fixed?
> > 
> > Please read bug reports before adding useless comments - in this case comment
> > 91. Also please do not fullquote the entire former posting without any reason,
> > please do not answer above the quote, and please read the basic stuff before
> > adding comments, such as the "Resolution" link which leads to
> > https://bugs.maemo.org/page.cgi?id=fields.html#resolution .
> > 
> many of us have been linux users before the n900 and are familier with the way
> bugzila works. however there are many who are new to all this. the best
> approach is to be polite and repond to comments in a respectful manner.

Correct. And it seems that this has been the case above.

This bug has been belaboured ad nauseam, and while it is difficult to go
through all of the almost 100 comments, one should really before commenting.
That's also part of the community spirit. I do not see any problem with Andre's
comment. It is polite, respectful, and to the point, following all the common
rules of public forums. And public forums are older than Linux, too. Remember
USENET? ;)

(Full disclosure: I do work for Nokia. However, I am in no way associated with
N900 or Maemo. My comments are my own, and do not necessarily reflect Nokia
position on any given topic.)
Comment 101 Venomrush 2010-01-18 07:54:42 UTC
To summarise, there are 5 different types of "*#" as mentioned by Lassi

1) SS procedures (e.g. *43# to activate call waiting)
2) SIM control procedures (e.g. **04*...# to change the PIN code)
3) IMEI presentation procedure (*#06#)
4) Manufacturer-defined procedures (e.g. *#0000#)
5) USSD commands (operator-defined, e.g. *100# to check prepaid credit)

PR1.1 only fixed 3 & 4

If 'those in charge' thinks it's fixed for this bug report and refuse to reopen
to fix 1 & 2 & 5, then we'll open new bug reports for them.
Comment 102 Neil MacLeod maemo.org 2010-01-18 12:27:58 UTC
*** Bug 8180 has been marked as a duplicate of this bug. ***
Comment 103 ossipena 2010-01-18 12:32:22 UTC
(In reply to comment #101)
> To summarise, there are 5 different types of "*#" as mentioned by Lassi
> 
> 1) SS procedures (e.g. *43# to activate call waiting)
> 2) SIM control procedures (e.g. **04*...# to change the PIN code)
> 3) IMEI presentation procedure (*#06#)
> 4) Manufacturer-defined procedures (e.g. *#0000#)
> 5) USSD commands (operator-defined, e.g. *100# to check prepaid credit)
> 
> PR1.1 only fixed 3 & 4
> 
> If 'those in charge' thinks it's fixed for this bug report and refuse to reopen
> to fix 1 & 2 & 5, then we'll open new bug reports for them.
> 

do you know what resolved fixed here means?
https://bugs.maemo.org/page.cgi?id=fields.html#resolution
Comment 104 Venomrush 2010-01-18 13:00:37 UTC
(In reply to comment #103)

> do you know what resolved fixed here means?
> https://bugs.maemo.org/page.cgi?id=fields.html#resolution
> 

No because Bugzilla made it too confusing.

There should only be 4 states for a bug

NEW - When bug first filled
OPEN - Bug verified exists
FIXED - Bug fixed 
CLOSED - Fix confirmed

'Status' and 'Resolution' combined in a bug confused everyone.

What I want to know is, have 

1) SS procedures (e.g. *43# to activate call waiting)
2) SIM control procedures (e.g. **04*...# to change the PIN code)
5) USSD commands (operator-defined, e.g. *100# to check prepaid credit)

been fixed for the next update? As no one seem to be able to give a definite
answer here.
Comment 105 ossipena 2010-01-18 13:03:00 UTC
(In reply to comment #104)
> (In reply to comment #103)
> 
> > do you know what resolved fixed here means?
> > https://bugs.maemo.org/page.cgi?id=fields.html#resolution
> > 
> 
> No because Bugzilla made it too confusing.
> 
> There should only be 4 states for a bug
> 
> NEW - When bug first filled
> OPEN - Bug verified exists
> FIXED - Bug fixed 
> CLOSED - Fix confirmed
> 
> 'Status' and 'Resolution' combined in a bug confused everyone.

this doesn't belong here

> What I want to know is, have 
> 
> 1) SS procedures (e.g. *43# to activate call waiting)
> 2) SIM control procedures (e.g. **04*...# to change the PIN code)
> 5) USSD commands (operator-defined, e.g. *100# to check prepaid credit)
> 
> been fixed for the next update? As no one seem to be able to give a definite
> answer here.
> 

As usual, nokia doesn't announce beforehand about anything. So you have just
wait for next update and see if it has been fixed.
Comment 106 Vladimir Oka 2010-01-18 13:06:52 UTC
(In reply to comment #104)
> (In reply to comment #103)
> 
> > do you know what resolved fixed here means?
> > https://bugs.maemo.org/page.cgi?id=fields.html#resolution
> > 
> 
> No because Bugzilla made it too confusing.
> 
> There should only be 4 states for a bug

Your view of software development and bug life cycles is too simplified.
This is also off-topic here.

> What I want to know is, have 
> 
> 1) SS procedures (e.g. *43# to activate call waiting)
> 2) SIM control procedures (e.g. **04*...# to change the PIN code)
> 5) USSD commands (operator-defined, e.g. *100# to check prepaid credit)
> 
> been fixed for the next update? As no one seem to be able to give a definite
> answer here.

If you have read all the comments before posting, you would have seen comment
#91 (https://bugs.maemo.org/show_bug.cgi?id=5357#c91) which clearly states
where the fix will be released in. 

Now just for PR1.2 to be released and we'll all be happy! ;)
Comment 107 Thorsten Trapp 2010-01-18 13:54:12 UTC
(In reply to comment #106)
> (In reply to comment #104)
> > (In reply to comment #103) 

> Now just for PR1.2 to be released and we'll all be happy! ;)
> 

https://bugs.maemo.org/show_bug.cgi?id=5380
From comment #5 onwards.

"2009.42: *31# and #31# for temporary CLIR control
2009.51: the above and *#06# for IMEI (+ Nokia-specific *#0000# for SW version)

A later update will bring full USSD support (covering e.g. the said *#1345#;
bug 5357), but it seems that Maemo 5 will not _officially_ support other MMI
codes."

Meaning: NO FULL SUPPORT OF *# MMI COMMANDS IN MAEMO5.
Especially NOT:
> 1) SS procedures (e.g. *43# to activate call waiting)
> 2) SIM control procedures (e.g. **04*...# to change the PIN code)
Comment 108 Lucas Maneos 2010-01-19 08:47:14 UTC
*** Bug 8242 has been marked as a duplicate of this bug. ***
Comment 109 Cristian Daniel Stamateanu 2010-01-22 16:18:13 UTC
Call me stupid, but the bug description and initial reports is about USSD
codes. From what I see those are the exact one left out at least for now. And
then the bug is marked as fixed/resolved. How come? 
From what I understand a bug is fixed and resolved when the bug was fixed in
the code and submitted to public review. Am I missing something?
Comment 110 Vladimir Oka 2010-01-22 16:39:32 UTC
(In reply to comment #109)
> From what I understand a bug is fixed and resolved when the bug was fixed in
> the code and submitted to public review. Am I missing something?

I think it's the case that a bug is "resolved" when it has been fixed and
verified *internally*. When it becomes available to public via update
mechanisms depends on internal Nokia plans, not shared with the public.

Somewhere among the 110 comments here, there was a SW version given that
includes the fix. When a public update includes it, or later SW, it will become
generally available.
Comment 111 Andre Klapper maemo.org 2010-01-22 16:41:26 UTC
(In reply to comment #109)
> From what I understand a bug is fixed and resolved when the bug was fixed in
> the code and submitted to public review. Am I missing something?

Yes. You forgot reading before commenting (and creating bugmail). ;-)
It has been explained several times in this thread already, but of course a bug
report becomes unreadable when more and more unhelpful comments are added to
it.
Comment 112 Radu Capitanu 2010-01-22 18:32:33 UTC
Hi! Anyone knows when This PR1.2 will be realised?
It's sad because in Romania the only option for cost control is *123#.
Please give me at least a clue about the date. I was written around here
something about an internal build version, something like 1.2010.02... If so,
can you help me to aproximate using this internal figures. Maybe a link who
explain how to do it.
Thank you!!!
Comment 113 Andre Klapper maemo.org 2010-01-22 18:36:59 UTC
(In reply to comment #112)
> Hi! Anyone knows when This PR1.2 will be realised?

You did read this report (comment 36, comment 63, comment 97, comment 111)
before commenting I assume? If so, what was not clearly explained in those
comments?

And again: BUGZILLA IS NOT A FORUM. I lean towards disabling some user accounts
here if this continues to be constantly ignored.
Comment 114 Sam (ABUSED BUGZILLA; ACCOUNT SUSPENDED) 2010-01-22 20:41:31 UTC
In Many countries after you make each call you get a message receipt screen
stating your balance. and the same screen comes while using USSD commands like
*1100#
Comment 115 Vladimir Oka 2010-01-22 20:52:07 UTC
Come on people!

Please stop spamming the bug tracker. If Andre has to read every repeated post
with no new and useful information, he'll have that much time less to deal with
real work and problems. him and the developers, too.

In the long run this will benefit us all...
Comment 116 Sam (ABUSED BUGZILLA; ACCOUNT SUSPENDED) 2010-01-22 21:19:43 UTC
(In reply to comment #115)
> Come on people!
> Please stop spamming the bug tracker. If Andre has to read every repeated post
> with no new and useful information, he'll have that much time less to deal with
> real work and problems. him and the developers, too.
> In the long run this will benefit us all...

Dear Vlad. I apologize for any disturbance which I caused in your valuable
time, but you have to understand that the world's cheapest phone recognizes
USSD commands but since Nokia has contracted Maemo, rest assured nokia users
will have to face perpetual torment.

Anyways a message for Mr. Andre is that as I mentioned after each call we get a
receipt for balance inquiry which does not appear on N900, instead! something
keeps in progress while the phone is Idle. I've checked it several times by
putting my N900 next to computer speakers and they keep on buzzing as someone
is trying to make call or expecting a message. I presume that the mobile
network tries to send receipt to the phone which the "Stubborn" Maemo does not
comprehend. 

I'm sure you gentlemen can look into that as well. 

P.S   I checked three N900s with the same issue so uncle Maemo needs to be
fixed
Comment 117 Lassi Syrjälä nokia 2010-01-22 22:53:56 UTC
(In reply to comment #116)
> Anyways a message for Mr. Andre is that as I mentioned after each call we get a
> receipt for balance inquiry which does not appear on N900, instead!

USSD can also be network-originated. Though I am quite surprised to hear it's
used after each call somewhere.  Part of the package anyways, but makes me
wonder if we made the UI too modal. We cannot really tell if the message is
something not to miss or "just" your balance.
Comment 118 Vladimir Oka 2010-01-22 22:59:48 UTC
(In reply to comment #117)
> ...
> Though I am quite surprised to hear it's
> used after each call somewhere.  Part of the package anyways, but makes me
> wonder if we made the UI too modal. We cannot really tell if the message is
> something not to miss or "just" your balance.

In fact O2 UK does the same. After an MO call or SMS you are sent a message
with the remaining balance. Similarly, the easiest way to get your balance is
to send *#10#, not currently supported on N900. Luckily, O2 allows you to dial
4445 as a voice call to top up/query balance. This is not such an unusual NW
feature.
Comment 119 Sam (ABUSED BUGZILLA; ACCOUNT SUSPENDED) 2010-01-22 23:47:30 UTC
> USSD can also be network-originated. Though I am quite surprised to hear it's
> used after each call somewhere.  Part of the package anyways, but makes me
> wonder if we made the UI too modal. We cannot really tell if the message is
> something not to miss or "just" your balance.

Balance receipt is an automated and free service from my cellular network which
pops up after every call or text message i send. There are 2 problems I am
facing. First is that it CAN NOT be disabled from the network where it's
originated and second is that it's the same (Window/Screen/Text Box) which
appears while we get different info using USSD Commands. Since the USSD's
message screen is unavailable, my cellular network tries to keep on sending
balance receipt which N900 never gets and turns out to keep phone busy by
hopeless struggles. 

As I mentioned earlier that after I make a call the "automated receipt" tries
to pop up on the screen but N900 wont let which results as a constant buzz from
my computer's monitor and speakers (The buzz you normally hear while the call
is in progress OR when you're about to receive an SMS)

And it wont go away till I put my phone in Offline mode.

What I'm trying to say is that we have another problem attached to this by not
having USSD service.
Comment 120 Vladimir Oka 2010-01-22 23:52:09 UTC
(In reply to comment #119)
> ...
> my cellular network tries to keep on sending
> balance receipt which N900 never gets and turns out to keep phone busy by
> hopeless struggles. 
> ...
> As I mentioned earlier that after I make a call the "automated receipt" tries
> to pop up on the screen but N900 wont let which results as a constant buzz from
> my computer's monitor and speakers...

In which case the best course of action is to raise a new bug report, to cover
the case of USSD codes being received, rather than sent. One problem, one bug
report. 

BTW, I am not seeing this issue on O2 UK which provides the same service as
your operator.
Comment 121 Attila Csipa nokia 2010-01-23 12:01:12 UTC
As a stopgap solution (mentioned in #88, but much improved since then), if you
REALLY REALLY need this feature and are not afraid to install an application
under development (BACKUP ! Might break things ! You have been warned !) based
on information snippets on this page, see this project:

https://garage.maemo.org/projects/ussd-widget/

To avoid keeping things clean, if you do not know how to install deb files, DO
NOT use this page for asking about that. Use the maemo.org wiki or search
around in talk.maemo.org. Feedback, contact with authors at

http://talk.maemo.org/showthread.php?t=32878&page=11
Comment 122 Ryan Abel maemo.org 2010-01-24 15:19:12 UTC
*** Bug 8464 has been marked as a duplicate of this bug. ***
Comment 123 Ryan Abel maemo.org 2010-01-25 12:17:48 UTC
*** Bug 8489 has been marked as a duplicate of this bug. ***
Comment 124 Nader 2010-01-26 09:34:21 UTC
(In reply to comment #122)
> *** Bug 8464 has been marked as a duplicate of this bug. ***
> 

I just want to confirm that **interactive** type of *100 numbers are considered
in bug 5357 where the service provider will send back a message prompting for
input.
Thank you
Comment 125 Lucas Maneos 2010-01-27 21:12:23 UTC
*** Bug 8585 has been marked as a duplicate of this bug. ***
Comment 126 Andre Klapper maemo.org 2010-02-02 13:54:54 UTC
*** Bug 8758 has been marked as a duplicate of this bug. ***
Comment 127 Charles 2010-02-02 16:29:56 UTC
Plz get this fixed at the earliest
Comment 128 Khaled 2010-02-03 16:35:55 UTC
Confirmed
Comment 129 Ryan Abel maemo.org 2010-02-04 19:34:59 UTC
*** Bug 8831 has been marked as a duplicate of this bug. ***
Comment 130 Andre Klapper maemo.org 2010-02-04 21:15:22 UTC
*** Bug 8830 has been marked as a duplicate of this bug. ***
Comment 131 Andre Klapper maemo.org 2010-02-13 01:42:36 UTC
*** Bug 9032 has been marked as a duplicate of this bug. ***
Comment 132 Andre Klapper maemo.org 2010-02-15 11:30:44 UTC
*** Bug 9058 has been marked as a duplicate of this bug. ***
Comment 133 Lucas Maneos 2010-02-24 12:16:13 UTC
*** Bug 9251 has been marked as a duplicate of this bug. ***
Comment 134 Lucas Maneos 2010-03-02 11:08:59 UTC
*** Bug 9346 has been marked as a duplicate of this bug. ***
Comment 135 Andre Klapper maemo.org 2010-03-03 13:04:58 UTC
*** Bug 9374 has been marked as a duplicate of this bug. ***
Comment 136 rrdbala 2010-03-06 05:46:04 UTC
(In reply to comment #135)
> *** Bug 9374 has been marked as a duplicate of this bug. ***
> 

I see thi bug as fixed. Does it mean it will be enabled on the next update ?
This is ab ver important feature & we must see this on the next update.
Comment 137 Venomrush 2010-03-06 13:45:48 UTC
(In reply to comment #136)
> (In reply to comment #135)
> > *** Bug 9374 has been marked as a duplicate of this bug. ***
> > 
> 
> I see thi bug as fixed. Does it mean it will be enabled on the next update ?
> This is ab ver important feature & we must see this on the next update.
> 

While you wait for the fix to be release for public, there is an immidiate
alternative solution by using USSD Widget -
http://maemo.org/packages/view/ussd-widget
Comment 138 bigbrovar 2010-03-06 14:51:56 UTC
(In reply to comment #137)
> (In reply to comment #136)
> > (In reply to comment #135)
> > > *** Bug 9374 has been marked as a duplicate of this bug. ***
> > > 
> > 
> > I see thi bug as fixed. Does it mean it will be enabled on the next update ?
> > This is ab ver important feature & we must see this on the next update.
> > 
> 
> While you wait for the fix to be release for public, there is an immidiate
> alternative solution by using USSD Widget -
> http://maemo.org/packages/view/ussd-widget
> 

ussd-widget never worked for me and many others. Nokia should not even try to
think that this bug has been fixed* by the community. They need to come out
with a proper fix. Its been hell using the n900 as the only mobile phone. And
the fact that 3 updates has been released and this not included in any of them
is frankly not inspiring. I am not asking for portrait mode support. or for
meego to be made available to N900. or for turn by turn Navigations. I am just
asking for a simple basic functionality which every single GSM device in the
world supports. Something which should have been included in the first place.
That is all we are asking. I have tried to be the good citizen. Vote for the
bug and wait for the fix to be released, and not try to add noise to this
report. But that does not mean I and many others who are less geeky than me are
not suffering because of this major and critical omission from Nokia. Please
guys who work at nokia and reading this bug report should talk to Nokia so that
this fix can be released. Tell them its critical and a real deal breaker.
making the lives of many of their users miserable. Thanks
Comment 139 Andre Klapper maemo.org 2010-03-06 15:37:35 UTC
(In reply to comment #138)
> ussd-widget never worked for me and many others. Nokia should not even try to
> think that this bug has been fixed* by the community.

And Nokia does not, as this will be fixed in the next update (as written a few
billion times in this report before), hence I stopped reading your comment at
this point. So please don't post such comments here, or go to talk.maemo.org
for telling Nokia what to do and what not to do. Thanks a lot!
Comment 140 Raj Gupta 2010-03-09 09:48:12 UTC
(In reply to comment #139)
> (In reply to comment #138)
> > ussd-widget never worked for me and many others. Nokia should not even try to
> > think that this bug has been fixed* by the community.
> And Nokia does not, as this will be fixed in the next update (as written a few
> billion times in this report before), hence I stopped reading your comment at
> this point. So please don't post such comments here, or go to talk.maemo.org
> for telling Nokia what to do and what not to do. Thanks a lot!

Greetings Vlad

I have purchased N900 two days ago and I couldnt find any word better than
"Disappointed" what N900 has to offer. Lack of USSD in a mobile phone is like a
person with no brain, no wonder all the qualified retards at Nokia and Maemo
have proven their lack of efficiency and brains. 

I just hope I'd come across CEO of Nokia and Maemo and make them witness as I
destroy this piece of bowel with sledge hammer. I had to save money to get this
phone and now I'm stuck with it! I desperately need to sell this phone and buy
some Chinese.

Thankyou.
Comment 141 Vladimir Oka 2010-03-09 09:57:22 UTC
(In reply to comment #140)
> (In reply to comment #139)
> > (In reply to comment #138)
> > > ussd-widget never worked for me and many others. Nokia should not even try to
> > > think that this bug has been fixed* by the community.
> > And Nokia does not, as this will be fixed in the next update (as written a few
> > billion times in this report before), hence I stopped reading your comment at
> 
> Greetings Vlad

I assume you mean Andre here, but I do agree with him... ;)

For ussd-widget not working the best thing is to complain to its author.
Comment 142 ossipena 2010-03-09 10:36:56 UTC
(In reply to comment #140)
> (In reply to comment #139)
> > (In reply to comment #138)
> > > ussd-widget never worked for me and many others. Nokia should not even try to
> > > think that this bug has been fixed* by the community.
> > And Nokia does not, as this will be fixed in the next update (as written a few
> > billion times in this report before), hence I stopped reading your comment at
> > this point. So please don't post such comments here, or go to talk.maemo.org
> > for telling Nokia what to do and what not to do. Thanks a lot!
> 
> Greetings Vlad
> 
> I have purchased N900 two days ago and I couldnt find any word better than
> "Disappointed" what N900 has to offer. Lack of USSD in a mobile phone is like a
> person with no brain, no wonder all the qualified retards at Nokia and Maemo
> have proven their lack of efficiency and brains. 
> 
> I just hope I'd come across CEO of Nokia and Maemo and make them witness as I
> destroy this piece of bowel with sledge hammer. I had to save money to get this
> phone and now I'm stuck with it! I desperately need to sell this phone and buy
> some Chinese.
> 
> Thankyou.
> 

http://talk.maemo.org is a place for things like that. I hope you get banned
for this stupid spam you put here.
Comment 143 Naba Kumar nokia 2010-03-09 10:41:22 UTC
Spare your angers. I will repeat comment #14

(In reply to comment #14)
> We are aware of missing USSD support, we plan to do it in some release update.
> 

"some release" is basically the next update.
Comment 144 Andre Klapper maemo.org 2010-03-14 21:15:49 UTC
*** Bug 9537 has been marked as a duplicate of this bug. ***
Comment 145 Andre Klapper maemo.org 2010-03-15 20:51:37 UTC
Setting explicit PR1.2 milestone (so it's clearer in which public release the
fix will be available to users).

Sorry for the bugmail noise (you can filter on this message).
Comment 146 Ibrahim (account disabled) 2010-04-05 04:08:40 UTC
i am sorry to say this
BUT NOKIA ARE STUPID 
how come no USSD 
OMG
and 3 updates and its still NOT FIXED
i wish i never bought my stupid N900 at jan
i should have wait tell the NEXT device ( meego ) to come out
NOKIA ARE STUPID
LOSER
I HATE NOKIA because of the N900
Comment 147 kv4nbee 2010-04-29 10:49:38 UTC
(In reply to comment #145)
> Setting explicit PR1.2 milestone (so it's clearer in which public release the
> fix will be available to users).
> 
> Sorry for the bugmail noise (you can filter on this message).
> 

so how come it's fixed if it's not!
i'm in Poland right now and can't even top up my balance
is there another solution/quickfix until(if/when/whenever) update is released?
Comment 148 ossipena 2010-04-29 11:29:31 UTC
(In reply to comment #147)
> (In reply to comment #145)
> > Setting explicit PR1.2 milestone (so it's clearer in which public release the
> > fix will be available to users).
> > 
> > Sorry for the bugmail noise (you can filter on this message).
> > 
> 
> so how come it's fixed if it's not!
> i'm in Poland right now and can't even top up my balance
> is there another solution/quickfix until(if/when/whenever) update is released?
> 
Please read this link through:

https://bugs.maemo.org/page.cgi?id=fields.html#resolution
Comment 149 Pelau Vadim 2010-04-29 11:54:00 UTC
(In reply to comment #147)
> (In reply to comment #145)
> > Setting explicit PR1.2 milestone (so it's clearer in which public release the
> > fix will be available to users).
> > 
> > Sorry for the bugmail noise (you can filter on this message).
> > 
> 
> so how come it's fixed if it's not!
> i'm in Poland right now and can't even top up my balance
> is there another solution/quickfix until(if/when/whenever) update is released?
> 

Install the USSD widget, look in the forum for details. It works great.
Comment 150 jean-francoisgarneau 2010-04-29 12:28:14 UTC
(In reply to comment #149)
> (In reply to comment #147)
> > (In reply to comment #145)
> > > Setting explicit PR1.2 milestone (so it's clearer in which public release the
> > > fix will be available to users).
> > > 
> > > Sorry for the bugmail noise (you can filter on this message).
> > > 
> > 
> > so how come it's fixed if it's not!
> > i'm in Poland right now and can't even top up my balance
> > is there another solution/quickfix until(if/when/whenever) update is released?
> > 
> 
> Install the USSD widget, look in the forum for details. It works great.
> 
For your information, USSD WIDGET DOESN'T WORK WITH FIDO (CARRIER) IN CANADA.
Comment 151 Pelau Vadim 2010-04-29 12:52:50 UTC
(In reply to comment #150)
> (In reply to comment #149)
> > (In reply to comment #147)
> > > (In reply to comment #145)
> > > > Setting explicit PR1.2 milestone (so it's clearer in which public release the
> > > > fix will be available to users).
> > > > 
> > > > Sorry for the bugmail noise (you can filter on this message).
> > > > 
> > > 
> > > so how come it's fixed if it's not!
> > > i'm in Poland right now and can't even top up my balance
> > > is there another solution/quickfix until(if/when/whenever) update is released?
> > > 
> > 
> > Install the USSD widget, look in the forum for details. It works great.
> > 
> For your information, USSD WIDGET DOESN'T WORK WITH FIDO (CARRIER) IN CANADA.
> 

Thanks for spelling it out so clearly. Then perhaps they have a non*# number as
well. Orange in EU has.

Either way I believe the update should be out next week.
Comment 152 Andre Klapper maemo.org 2010-05-02 17:31:51 UTC
*** Bug 10078 has been marked as a duplicate of this bug. ***
Comment 153 Andre Klapper maemo.org 2010-05-21 16:46:05 UTC
*** Bug 10217 has been marked as a duplicate of this bug. ***
Comment 154 Andre Klapper maemo.org 2010-05-23 16:12:52 UTC
*** Bug 10242 has been marked as a duplicate of this bug. ***
Comment 155 Andre Klapper maemo.org 2010-05-25 11:16:17 UTC
*** Bug 10259 has been marked as a duplicate of this bug. ***
Comment 156 Adam 2010-05-26 20:00:42 UTC
(In reply to comment #155)
> *** Bug 10259 has been marked as a duplicate of this bug. ***
> 
This is still not fixed in PR1.2!
Comment 157 Vladimir Oka 2010-05-26 20:52:35 UTC
(In reply to comment #156)
> (In reply to comment #155)
> > *** Bug 10259 has been marked as a duplicate of this bug. ***
> > 
> This is still not fixed in PR1.2!
> 

It seems to work for me. What exact codes have you tried that have failed?
Comment 158 I/O 2010-05-26 20:55:44 UTC
(In reply to comment #156)
> (In reply to comment #155)
> > *** Bug 10259 has been marked as a duplicate of this bug. ***
> > 
> This is still not fixed in PR1.2!
> 

It works very well for me!
Very nice to make link to desktop and tap for the info ;)
Comment 159 Andrew 2010-05-26 23:03:02 UTC
Still does not work for me in PR1.2. Trying to change my outgoing caller ID by
entering the following command: *004*[phonenumber]# gives the error "service
code not supported"
Comment 160 Vladimir Oka 2010-05-26 23:05:15 UTC
(In reply to comment #159)
> Still does not work for me in PR1.2. Trying to change my outgoing caller ID by
> entering the following command: *004*[phonenumber]# gives the error "service
> code not supported"
> 

Are you sure your operator supports this code? The message you get looks
suspiciously like a reply you'd get from the network if it wasn't. Have you
tried the same command on a different phone (with the same SIM, in the same
place).
Comment 161 Pelau Vadim 2010-05-26 23:21:03 UTC
In my country the format is usually *[some number]# and all invalid
combinations such as yours (for my operator) give a "request not completed"
message after a short while - not instant!

Looks to me that the code is being sent...
Comment 162 Attila Csipa nokia 2010-05-26 23:26:15 UTC
THIS bug/enhancement is fixed. If there is a specific code/operator that does
not work, please doublecheck with different phone and same SIM, and potentially
open a new bug if it really IS up to Maemo5, but the generic 'has no *#
support' is certainly not an issue any more (verified).
Comment 163 jean-francoisgarneau 2010-05-27 01:24:33 UTC
(In reply to comment #162)
> THIS bug/enhancement is fixed. If there is a specific code/operator that does
> not work, please doublecheck with different phone and same SIM, and potentially
> open a new bug if it really IS up to Maemo5, but the generic 'has no *#
> support' is certainly not an issue any more (verified).
> 
I am from Canada and I am unsing fido.

With the same SIM card, USSD code works with my old Motorolla but they don't
work with my Nokia N900 and the new firmware.  So, it is not an code/operator
issue.  It is a Nokia N900 issue.
Comment 164 Andre Klapper maemo.org 2010-05-27 01:39:14 UTC
(In reply to comment #163)
Please avoid vague comments. If something does not work and you are SURE that
this is related at all to this bug, add *EXACT* steps.
If not or if you are in doubt, please go to talk.maemo.org first.

Also, please read comment 47 first to understand about the differences of
existing codes.
Comment 165 jean-francoisgarneau 2010-05-27 01:56:53 UTC
(In reply to comment #164)
> (In reply to comment #163)
> Please avoid vague comments. If something does not work and you are SURE that
> this is related at all to this bug, add *EXACT* steps.
> If not or if you are in doubt, please go to talk.maemo.org first.
> 
> Also, please read comment 47 first to understand about the differences of
> existing codes.
> 
«Please avoid vague comments.»

SOFTWARE VERSION:
10.2010.19-1.002

STEPS TO REPRODUCE THE PROBLEM:
1. Open Phone to make a call.
2. #21#
3. Click on Call-button

EXPECTED OUTCOME:
cancel Call Forwarding

ACTUAL OUTCOME:
Service code not supported

REPRODUCIBILITY:
always

CARRIER: WWW.FIDO.CA

SEE THE PROBLEM ON YOUTUBE: http://www.youtube.com/watch?v=_76aeo9UXEk
Comment 166 shahzad 2010-05-27 07:19:39 UTC
WOW Update of MEMO resolve the USSD code problem now all Prepaid users can
check there balance or execute any query to us USSD like *123# its working
perfectly 
Thanks Memo Team to resolve this problem
Comment 167 Pelau Vadim 2010-05-27 08:54:19 UTC
(In reply to comment #165)
> (In reply to comment #164)
> > (In reply to comment #163)
> > Please avoid vague comments. If something does not work and you are SURE that
> > this is related at all to this bug, add *EXACT* steps.
> > If not or if you are in doubt, please go to talk.maemo.org first.
> > 
> > Also, please read comment 47 first to understand about the differences of
> > existing codes.
> > 
> «Please avoid vague comments.»
> 
> SOFTWARE VERSION:
> 10.2010.19-1.002
> 
> STEPS TO REPRODUCE THE PROBLEM:
> 1. Open Phone to make a call.
> 2. #21#
> 3. Click on Call-button
> 
> EXPECTED OUTCOME:
> cancel Call Forwarding
> 
> ACTUAL OUTCOME:
> Service code not supported
> 
> REPRODUCIBILITY:
> always
> 
> CARRIER: WWW.FIDO.CA
> 
> SEE THE PROBLEM ON YOUTUBE: http://www.youtube.com/watch?v=_76aeo9UXEk
> 

Yes he's right #21# doesn't work. We should however start a bug thread for ##
issues. My operator however does not use such numbers.
Comment 168 Naba Kumar nokia 2010-05-27 12:34:05 UTC
(In reply to comment #167)
> 
> Yes he's right #21# doesn't work. We should however start a bug thread for ##
> issues. My operator however does not use such numbers.
> 

Please note that this bug is about USSD codes, which is fixed and reported to
be working by many.

Don't confuse it with SS codes (see comment #47 and various comments by Lassi).
SS codes is not officially enabled in PR1.2, mainly because most useful actions
are more conveniently done by UI in (Settings->Phone settings) such as call
forwarding, Call ID enable/disable etc.). These are legacy codes, so don't get
bogged down by this -- just visit your "Phone Settings". Less useful ones are
less useful, anyways.

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 :).
Comment 169 Paulo Ricardo Ribeiro 2010-05-27 13:32:22 UTC
*111# Portugal -> Optimus -> Works fine
Comment 170 Joao Pinto 2010-05-27 13:35:44 UTC
Works perfectly with *....# codes
Comment 171 Graham Cobb maemo.org 2010-05-27 14:07:08 UTC
(In reply to #168)

In my view, not supporting SS codes is a big mistake.  There are many reasons,
including the fact that users do not understand the difference between
different types of codes.  But the main reason is that they are not "legacy",
they are "standard"!

Every GSM phone I have had (last 15 years or so), I have had entries in my
phonebook for quickly changing forwarding settings (forward to work, forward to
home, cancel forwarding).  Users use the SS codes.  I want to put a widget on
my home screen to set up forwarding to home with a single click!

Either a new bug needs to be created, or this one needs to be reopened, for SS
code support.
Comment 172 Andre Klapper maemo.org 2010-05-27 14:15:38 UTC
(In reply to comment #171)
> Either a new bug needs to be created, or this one needs to be reopened, for SS
> code support.

New request, as this report is pretty useless thanks to many people abusing it
as a forum, and as this report is about *#.
Comment 173 Pelau Vadim 2010-05-27 14:39:28 UTC
(In reply to comment #171)
> (In reply to #168)
> 
> In my view, not supporting SS codes is a big mistake.  There are many reasons,
> including the fact that users do not understand the difference between
> different types of codes.  But the main reason is that they are not "legacy",
> they are "standard"!
> 
> Every GSM phone I have had (last 15 years or so), I have had entries in my
> phonebook for quickly changing forwarding settings (forward to work, forward to
> home, cancel forwarding).  Users use the SS codes.  I want to put a widget on
> my home screen to set up forwarding to home with a single click!
> 
> Either a new bug needs to be created, or this one needs to be reopened, for SS
> code support.
> 

I suggest a new bug report or even a brainstorm.
Comment 174 Thorsten Trapp 2010-05-27 15:08:02 UTC
No new bug report needed, I guess this can be revived. Basicially requesting
full 
3GPP TS 22.030 compatibility. (explicitly including SS)
https://bugs.maemo.org/show_bug.cgi?id=8830


(In reply to comment #173)
> (In reply to comment #171)
> > (In reply to #168)
> > 
> > In my view, not supporting SS codes is a big mistake.  There are many reasons,
>
Comment 175 Andre Klapper maemo.org 2010-05-27 15:18:01 UTC
(Please avoid quoting the complete previous comment and answering above.)

(In reply to comment #174)
> No new bug report needed, I guess this can be revived.

Again: New bug welcome. This bug is unusable "thanks" to forum-like comments in
Bugzilla which is not a new forum. 
-- Your friendly bugmaster.
Comment 176 Naba Kumar nokia 2010-05-27 17:47:29 UTC
(In reply to comment #171)
> 
> In my view, not supporting SS codes is a big mistake.  There are many reasons,
> including the fact that users do not understand the difference between
> different types of codes.  But the main reason is that they are not "legacy",
> they are "standard"!
> 
Now that you know you can do the same thing from UI, would you still insist on
using the codes? "Legacy" is the codes part, not the functional part. These
were mainly created for dump phones, not for UI rich phones like N900. As for
standard compliance, let Nokia worry about it.

If you see that "Phone Settings" miss any useful features (that you have been
doing with SS codes), please feel free to file them as separate bug. And please
be specific about the feature and how it impacts your usage (i.e. don't file a
bug like "N900 should be standard compliance" or similar).

> Every GSM phone I have had (last 15 years or so), I have had entries in my
> phonebook for quickly changing forwarding settings (forward to work, forward to
> home, cancel forwarding).  Users use the SS codes.  I want to put a widget on
> my home screen to set up forwarding to home with a single click!
> 
Sounds like this is what you are after:
http://maemo.org/downloads/product/Maemo5/callforwarding/
If you need improvements in it's UI, please feel free to file bugs to it for
the author.
Comment 177 Graham Cobb maemo.org 2010-05-27 18:43:11 UTC
(In reply to comment #176)
> Now that you know you can do the same thing from UI, would you still insist on
> using the codes? 

Yes, for particular purposes.  I have been using them for 15 years.  They are
documented all over the web.  They work on all phones.  Nokia should not
arrogantly decide which parts of the standards they will choose to implement --
the standards are written for *my* convenience, as a user, not theirs.

Imagine what would happen if Nokia suddenly decided that it would not support
dialing "+" to indicate international numbers, but provided a GUI button to
make international calls!

> 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.
Comment 178 Lassi Syrjälä nokia 2010-05-27 18:44:33 UTC
(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.
Comment 179 jean-francoisgarneau 2010-05-29 05:11:22 UTC
(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.
> 

Thank you very much  M. Lassi Syrjälä.  Your solution solved my *21# problem
:-)
Comment 180 MKDerb 2010-07-18 10:31:32 UTC
This Bug is confirmed with me also
I use 
**62*737#
##62#
**21*737#
##21#
Comment 181 ossipena 2010-07-18 10:47:29 UTC
(In reply to comment #180)
> This Bug is confirmed with me also
> I use 
> **62*737#
> ##62#
> **21*737#
> ##21#
> 

khrm which one starts with "*#" as per description?
Comment 182 John Veness 2010-07-18 13:20:14 UTC
(In reply to comment #181)
> which one starts with "*#" as per description?

I believe the description should say "Does not accept GSM (USSD) Codes starting
with * or #".
Comment 183 Andre Klapper maemo.org 2010-07-18 13:28:23 UTC
No, as we prefer specific bug reports instead of dumping several issues into
one ticket. Please query if there is an existing ticket for your issue as it is
unrelated to this issue.
Comment 184 flerchjj 2011-10-30 07:38:53 UTC
Issue seems to be there (or back) in PR1.3
Comment 186 this_herd_of_these_horses 2015-05-15 02:20:22 UTC
I get "service code not supported" with **62*0xyzxyzxyz# in Phone... Not sure
if it is expected behavior or not.