Ticket #2038 (in_testing enhancement)

Opened 10 years ago

Last modified 10 years ago

Qtopia USSD requests support

Reported by: Treviño Owned by: tick
Priority: normal Milestone:
Component: Qtopia Version: Om2008.9-dev
Severity: normal Keywords: HasPatch
Cc: Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: yes PatchReviewResult:
Reproducible: always

Description

Finally I'm able to post the patch I've done for supporting USSD requests in qtopia. It isn't perfect but it works in all the situations I've tried and works also with the UCS2 codec (recently set as the default one).

Added basic support for Unstructured Supplementary Service Data (USSD) requests following the rules stated in 3GPP TS 22.090 document.
This fixes also the dialing of numbers containing '*' or '#' but that don't match the USSD rules removing also some duplications of the Qtopia code. I've also moved the parsing of these numbers in qmodemcall, this will allow to remember these special calls in the dialed numbers (imho it's better, but it could be easily moved back to gsmkeyactions).

To support the UCS2 codec (and others I figure), I've added a small workaround to make the modem use always the GSM (using the IRA would have been the same) codec for placing USSD requests, while it should be able to get them in any format.

This should fix the Openmoko bugs #1226, #1832, #2029.

Attachments

qtopia-add-support-for-USSD-requests.patch (8.9 KB) - added by Treviño 10 years ago.
[PATCH] Add support for USSD requests to the network
0001-Move-detecting-of-supplementary-service-detection-to.patch (2.7 KB) - added by zecke 10 years ago.
Move the detection to qmodemcall
0002-gsm-Switch-the-encoding-before-sending-a-supplemen.patch (2.0 KB) - added by zecke 10 years ago.
Force GSM charset before dialing supplementary numbers

Change History

Changed 10 years ago by Treviño

[PATCH] Add support for USSD requests to the network

comment:1 Changed 10 years ago by zecke

Wow. Good stuff. I will need some time to apply it though.

comment:2 Changed 10 years ago by zecke

Okay first thoughts:

  • Moving the matching to QModemCall is good and I will take that
  • Removing public API (specially only the implementation) even if it is called is not good.
  • 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?

Changed 10 years ago by zecke

Move the detection to qmodemcall

Changed 10 years ago by zecke

Force GSM charset before dialing supplementary numbers

comment:3 follow-up: ↓ 4 Changed 10 years ago by zecke

What is left from my point of view:

  • Understand why ATD needs to have the other encoding
  • Fix sending of AT+CUSD, this should be done by encoding the data properly

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.

Can you be happy with the code? I put the code here and not in the git repo as review works both ways.

comment:4 in reply to: ↑ 3 Changed 10 years ago by Treviño

Replying to 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 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...

comment:5 Changed 10 years ago by tick

  • Owner changed from zecke to tick
  • Status changed from new to accepted

comment:6 Changed 10 years ago by tick

  • Status changed from accepted to in_testing

Switch to in_testing

comment:7 Changed 10 years ago by tick

  • Status changed from in_testing to assigned

Oh ~ Sorry It's my fault. It's not there yet.

comment:8 Changed 10 years ago by Treviño

I've seen the git commit 91d64283e87eb3223bfcdd16d68a7a20b765fd7c that with the others recently added should add support for USSD, btw there are things that I don't understand (also if I've not tested these changes in my hardware yet):

  • Why the CUSD command is used (in order of the ATD one) only in the calypso modem? I know that we're using only that in Om, but all the GSM modems use the CUSD command to ask USSD requests...
  • Why in dialServiceCommand() you encode the string number using the current codec but you don't update the relative data coding scheme (dcs)? I mean, actually in any case is sent something like AT+CUSD=1,"<coded-dialed-string>",15 while the "15" value should change according to the GSM 03.38, isn't it? 15 stands for 1111 and so for "Language unspecified" according to that reference.

An I wrong?

comment:9 Changed 10 years ago by zecke

Why:

  • Issueing a charset change is dangerous as it can creates a window where saving something on the phonebook might fail as a command gets inserted in between. Even while the window is very small and unlikely to be hit I have fixed many of this kind of issues in the Qtopia code already. I try to avoid it.
  • Doing it from the vendor plugin fits best with the current structure of the code. It also solves the issue of a default charset nicely. It is set by the plugin, it is handled by the plugin.
  • From reading the specs we are not sure if setting AT+CSCS should have a influence on the USSD encoding. The spec says default is GSM 7 Bit and later something else. So we have no idea how other modems handle it, this is another reason to put it into the fic code path.


encoding:

  • Because of #2029 I'm not really sure that 15 means. We will have to figure out. There is no USSD service in taipei so I have to do the checking and adjusting when I'm back in germany. Feel free to test earlier. We pushed the changes as I believe the structure is the right one. :)

comment:10 Changed 10 years ago by roh

  • HasPatchForReview set

BatchModify?: set HasPatchForReview? on 'keyword' contains 'patch'

comment:11 Changed 10 years ago by zecke

Okay, I still need to test this in Europe, maybe during the next weekend.

comment:12 Changed 10 years ago by tick

  • Status changed from assigned to in_testing
Note: See TracTickets for help on using tickets.