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