Openmoko Bug #2038: Qtopia USSD requests support
Openmoko Public Trac
bugs at docs.openmoko.org
Sat Sep 27 03:36:30 CEST 2008
#2038: Qtopia USSD requests support
----------------------------+-----------------------------------------------
Reporter: Treviño | Owner: zecke
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: Qtopia | Version: Om2008.9-dev
Severity: normal | Resolution:
Keywords: HasPatch | Blockedby:
Reproducible: always | Blocking:
----------------------------+-----------------------------------------------
Comment(by Treviño):
Replying to [comment:2 zecke]:
> Okay first thoughts:
> - Moving the matching to QModemCall is good and I will take that
Ok...
> - Removing public API (specially only the implementation) even if it
is called is not good.
Ah, I thought it was redoundant...
> - The CSCS query and the resulting duplication is not good. From what
I assume is that with AT+CUSD we could send the right data?
Well, I added that since I didn't know that I could define how to perform
an action just for a class of devices (for a specific modem), so the best
way I found was that of reading the pre-set codec, setting the right one
and then going back to the default one.
Btw I had to make CUSD incoming data work in two situations:
- Parsing it correctly when I requested it and so when I've set a
specified codec
- Parsing it correctly when I don't requested it directly (i.e. the
network send me a "flash message" or simply informs me of how much I've
spent in the just endend call) and so when I don't know what codec I'm
using.
While in the first case I know what codec I must use, if I've set it; in
the second case I just have to check CSCS to get the codec that the modem
is using and then calling the right decoding method.
However, yes. We must use AT+CUSD to send the data... The mentioned 3GPP
documents should give you more informations about this.
Replying to [comment:3 zecke]:
> What is left from my point of view:
> - Understand why ATD needs to have the other encoding
Well... ATD imho should be removed at all from this part, since (according
to what I've read in the 3GPP docs) it isn't used at all for service
calls.
It must be used only for standard call...
> - Fix sending of AT+CUSD, this should be done by encoding the data
properly
I've tried to do that, but I always got modem errors... I figure that I
was using a bad encoding the network would have informed me about using
the right syntax sending me a CUSD error, but this never happens.
I only collected modem errors (I've not saved the error codes I got, but
some were like "memory error"), nothing goes to the network and this seems
strange to me.
Also, according to the 3GPP docs I found that the request should define
the codec used; so ''maybe'' using something like AT+CUSD="<number-coded-
in-ucs2>",<code-for-ucs2> should work anyway. While the number could be
coded using the functions available (I guess, since they're not so far
from SMS hadling) the <code-for-ucs2> according to GSM 03.38 should be
01001000 that is 72 in decimal... However I'm only wondering this...
> E.g. in your crash report I think it is crashing because you removed a
method from the library that is called by the gsm*.cpp code.
Thanks, I'll check also if I thought I had recompiled/relinked
everything...
> Can you be happy with the code? I put the code here and not in the git
repo as review works both ways.
If I find time in this weekend I'll give a try, but it seems ok in the
codec management. I don't know how you'd implement the request...
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2038#comment:4>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
More information about the buglog
mailing list