Closed Bug 1007535 Opened 11 years ago Closed 9 years ago

[B2G][Emulator] Support UNSOLICITED_ON_USSD in emulator

Categories

(Firefox OS Graveyard :: Emulator, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(tracking-b2g:backlog)

RESOLVED FIXED
tracking-b2g backlog

People

(Reporter: edgar, Assigned: edgar)

References

Details

(Whiteboard: [ft:ril])

Attachments

(3 files, 6 obsolete files)

Add support for UNSOLICITED_ON_USSD in emulator, and we can write some test case for it. Please see, 1. RIL_UNSOL_ON_USSD [1] 2. AT+CUSD [2] [1] https://github.com/mozilla-b2g/platform_hardware_ril/blob/master/include/telephony/ril.h#L3440-L3461 [2] TS 27.007 session 7.15
My idea is adding a console command to generate USSD UNSOLICITED response.
Assignee: nobody → echen
Whiteboard: [ft: ril]
Attached file platform_hardware_ril: PR#36 (obsolete) —
Attached file platform_external_qemu: PR #81 (obsolete) —
Will attach test script later.
Comment on attachment 8419950 [details] [review] platform_hardware_ril: PR#36 Hi Vicamo, could you help to review this? Thank you.
Attachment #8419950 - Flags: review?(vyang)
Attachment #8419999 - Flags: review?(vyang)
Attachment #8420141 - Attachment is obsolete: true
Attachment #8420738 - Flags: review?(vyang)
Landing sequence: 1). external/qemu and hardware/ril pull requests 2). Gecko patch
Oh, I uploaded a wrong patch (v2), attach correct one (v3) now, sorry for the noise.
Attachment #8420738 - Attachment is obsolete: true
Attachment #8420738 - Flags: review?(vyang)
Attachment #8420740 - Flags: review?(vyang)
Comment on attachment 8419950 [details] [review] platform_hardware_ril: PR#36 Some nits to be addresses. Thank you.
Attachment #8419950 - Flags: review?(vyang) → review+
Comment on attachment 8419950 [details] [review] platform_hardware_ril: PR#36 After more offline discuss, network initiated USSD responses are of format "+CUSD: <m>[,<str>,<dcs>]", which follows <dcs> and <str> must appear as a pair. Besides, that <str> is a USSDstring, not plain text. In order to be more spec conforming, these differences have to be resolved first.
Attachment #8419950 - Flags: review+
Comment on attachment 8419999 [details] [review] platform_external_qemu: PR #81 Per comment 16, we need a way to specify <dcs> on console command interface and convert input string to corresponding format accordingly.
Attachment #8419999 - Flags: review?(vyang)
Attachment #8420740 - Flags: review?(vyang)
Whiteboard: [ft: ril] → [ft: ril][p=2]
Target Milestone: --- → 2.0 S2 (23may)
Whiteboard: [ft: ril][p=2] → [ft:ril][p=2]
Blocks: b2g-emulator
blocking-b2g: --- → backlog
defer to sprint3 as it's not resolved yet.
Target Milestone: 2.0 S2 (23may) → 2.0 S3 (6june)
According to (In reply to Vicamo Yang [:vicamo][:vyang] from comment #12) > Comment on attachment 8419950 [details] [review] > platform_hardware_ril: PR#36 > > After more offline discuss, network initiated USSD responses are of format > "+CUSD: <m>[,<str>,<dcs>]", which follows <dcs> and <str> must appear as a > pair. Besides, that <str> is a USSDstring, not plain text. In order to be > more spec conforming, these differences have to be resolved first. Hmm, The message in RIL_UNSOL_ON_USSD is a plain text (in UTF-8) [1], so we need to decode "USSDstring" based on "Cell Broadcast Data Coding Scheme" in reference-ril. There is a lot of work needed to be done in reference-ril. [1] https://github.com/mozilla-b2g/platform_hardware_ril/blob/master/include/telephony/ril.h#L3440-L3462
Whiteboard: [ft:ril][p=2] → [ft:ril]
Target Milestone: 2.0 S3 (6june) → ---
blocking-b2g: backlog → ---
No longer blocks: 1198676
Hi Edgar, I revisited comment 13 and comment 15 again, and want to raise a question here. I understand the concern in comment 13 and comment 15 is for 3gpp compliance. However, as in our ussd session gecko code, we don't handle encoding/decoding that I am concerned this compliance with complexity in implementation doesn't provide us a lot value. IMHO your current WIP is prefect enough to help our testing. If we are concerned the "compliance" do you think it's acceptable that we introduce a new AT-command by our own that takes plan text as a parameter?
Flags: needinfo?(echen)
(In reply to Hsin-Yi Tsai [:hsinyi] from comment #17) > Hi Edgar, > I revisited comment 13 and comment 15 again, and want to raise a question > here. I understand the concern in comment 13 and comment 15 is for 3gpp > compliance. However, as in our ussd session gecko code, we don't handle > encoding/decoding that I am concerned this compliance with complexity in > implementation doesn't provide us a lot value. IMHO your current WIP is > prefect enough to help our testing. If we are concerned the "compliance" do > you think it's acceptable that we introduce a new AT-command by our own that > takes plan text as a parameter? Thanks for raising this. I agree with you that following spec in this case doesn't provide us a lot value. Introducing our own AT-command sounds good to me as we won't break the 3gpp standard. Will update the PR.
Flags: needinfo?(echen)
Attachment #8419999 - Attachment is obsolete: true
Attachment #8419950 - Attachment is obsolete: true
Comment on attachment 8689950 [details] [review] [platform_external_qemu:b2g-kitkat] PR #173 Hi Hsinyi, may I have your review for this PR? I introduce a new AT-Command with 'M' prefix which takes plan text as a ussd message. Thank you.
Attachment #8689950 - Flags: review?(htsai)
Attachment #8689956 - Flags: review?(htsai)
Comment on attachment 8689950 [details] [review] [platform_external_qemu:b2g-kitkat] PR #173 Looks good to me, thank you!
Attachment #8689950 - Flags: review?(htsai) → review+
Comment on attachment 8689956 [details] [review] [platform_hardware_ril:b2g-kitkat] PR #74 Left a minor comment on github. r=me thank you.
Attachment #8689956 - Flags: review?(htsai) → review+
I mis-deleted the local branch which is used for PR #74, so I create a new PR again.
Attachment #8689956 - Attachment is obsolete: true
Attachment #8692856 - Flags: review+
Comment on attachment 8420740 [details] [diff] [review] Marionette test for ussd received event, v3 Mark this as obsolete as this patch doesn't work on the latest main trunk due to WebAPI changes.
Attachment #8420740 - Attachment is obsolete: true
This is an example to show how to use the new command Edgar introduced in Telephony marionette-webapi tests.
I may be wrong but I don't see how one can send null/empty message using the newly added |ussd unsol| command?
Comment on attachment 8689950 [details] [review] [platform_external_qemu:b2g-kitkat] PR #173 Reverting the r+ flag per comment 28. I also left a comment on github. Thank you.
Attachment #8689950 - Flags: review+ → review?(htsai)
(In reply to pierre-eric from comment #28) > I may be wrong but I don't see how one can send null/empty message using the > newly added |ussd unsol| command? I have updated the PR, now you can send null/empty message by |ussd unsol <type>|. Could you try again? Thank you.
Flags: needinfo?(pierre-eric)
(In reply to Edgar Chen [:edgar][:echen] from comment #30) > I have updated the PR, now you can send null/empty message by |ussd unsol > <type>|. Could you try again? Thanks it's working now.
Flags: needinfo?(pierre-eric)
(In reply to pierre-eric from comment #31) > (In reply to Edgar Chen [:edgar][:echen] from comment #30) > > I have updated the PR, now you can send null/empty message by |ussd unsol > > <type>|. Could you try again? > > Thanks it's working now. Since it's working now, may I have your review again, Hsinyi? Thank you.
Flags: needinfo?(htsai)
Comment on attachment 8689950 [details] [review] [platform_external_qemu:b2g-kitkat] PR #173 works like a charm!
Flags: needinfo?(htsai)
Attachment #8689950 - Flags: review?(htsai) → review+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: