I'm afraid this issue is pretty much related with 818393 but here's some difference. I think call barring is already supporting through the following procedure. 1. Put MMI code(*35*0000#) on the device A. 2. The phone screen of A's is continuously progressing. 3. Make a MT call from device B. 4. Check device A and B 5. The call from B is barred by A. At that time the logs are like this; 24 01-23 19:54:49.579 D 128 RIL_QC_B2G [0315]> SET_FACILITY_LOCK 26 01-23 19:54:52.579 E 128 RIL_QC_B2G invalid command block for response SET_FACILITY_LOCK

(In reply to leo.bugzilla.gecko from comment #0) > I'm afraid this issue is pretty much related with 818393 but here's some > difference. > I think call barring is already supporting through the following procedure. > > > 1. Put MMI code(*35*0000#) on the device A. > 2. The phone screen of A's is continuously progressing. > 3. Make a MT call from device B. > 4. Check device A and B > 5. The call from B is barred by A. > > > At that time the logs are like this; > > 24 01-23 19:54:49.579 D 128 RIL_QC_B2G [0315]> SET_FACILITY_LOCK > 26 01-23 19:54:52.579 E 128 RIL_QC_B2G invalid command block for response > SET_FACILITY_LOCK The B2G RIL reference implementation does not support call barring yet.

Thank you for your immediate response. Then, is there any plan or due date for supporting call barring?

(In reply to leo.bugzilla.gecko from comment #2) > Thank you for your immediate response. > Then, is there any plan or due date for supporting call barring? Mmm, that's a product/roadmap decision. Don't know anything about it.

Call baring is not supported in B2G's RIL reference implementation so we not should close this bug IMHO, should we?. See bug 818393.

Indeed, we shouldn't close this bug. (In reply to leo.bugzilla.gecko from comment #2) > Then, is there any plan or due date for supporting call barring? Adding Daniel and Beatriz in CC as they might have an answer for your question.

IIRC this is not planned for v1.1, but i am adding need info for product team.

Even if this feature is not planned for v1.1 the bug should not be closed unless it is a product decision to *never* support call barring in Firefox OS. A bug not being a blocker doesn't mean that it does not need to be fixed.

Go for it!

WIP

Comment on attachment 779636 [details] [diff] [review] 833754.patch Review of attachment 779636 [details] [diff] [review]: ----------------------------------------------------------------- Need some feedback. ::: dom/system/gonk/ril_worker.js @@ +5238,5 @@ > + > + if (options.success && (options.rilMessageType === "sendMMI")) { > + options.statusMessage = MMI_SM_KS_SERVICE_INTERROGATED; > + // Buf.readUint32List()[0] for Call Barring is a bit vector of services. > + options.additionalInformation = Buf.readUint32List()[0]; Carol, the bit vector of services is returned in `options.additionalInformation` property and will let gaia handle and show that info in the MMI UI. Is that approach also valid for you guys? Thanks!

Comment on attachment 779636 [details] [diff] [review] 833754.patch Review of attachment 779636 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/system/gonk/ril_worker.js @@ +5238,5 @@ > + > + if (options.success && (options.rilMessageType === "sendMMI")) { > + options.statusMessage = MMI_SM_KS_SERVICE_INTERROGATED; > + // Buf.readUint32List()[0] for Call Barring is a bit vector of services. > + options.additionalInformation = Buf.readUint32List()[0]; Hi Antonio, based on this change, 'options.additionalInformation' just contains the list of service classes for which Call Barring is enabled for. However, Gaia wouldn't (and probably shouldn't need to) know what service class matches to it's string version, i.e. Voice/Data/SMS. Please refer to https://bugzilla.mozilla.org/show_bug.cgi?id=879694#c5 for some examples I had shared with Fernando about success and error cases for Call Barring.

(In reply to Carol Yang [:cyang] from comment #11) > Hi Antonio, based on this change, 'options.additionalInformation' just > contains the list of service classes for which Call Barring is enabled for. > However, Gaia wouldn't (and probably shouldn't need to) know what service > class matches to it's string version, i.e. Voice/Data/SMS. Agree. > Please refer to https://bugzilla.mozilla.org/show_bug.cgi?id=879694#c5 for > some examples I had shared with Fernando about success and error cases for > Call Barring. Ok, I'll change my WIP. Thanks!

Carol, feedback comments from comment #11 addressed. Could you check whether this is more or less what you guys do in your RIL implementation please? Thanks.

Fernando, this patch add support for handling call barring supplementary services through MMI commands. Could you take a look please? Thanks!

Hi José: I believe test case - test_ril_worker_mmi.js also need to be revised, or, we will got failure result on running mmi related TCs. add_test(function test_sendMMI_call_barring() { testSendMMI("*33#", "CALL_BARRING_NOT_SUPPORTED_VIA_MMI"); run_next_test(); }); Thanks!! sku

In addition, FACILITY is not only for CallBarring, but also for SIM PIN/PIN2 etc... (see 3GPP 27.007 clause 7.4). Besides CallBarring, we also need to consider not to impact the other features that FACILITY related to. Thanks!! sku

(In reply to sku from comment #15) > Hi José: > I believe test case - test_ril_worker_mmi.js also need to be revised, or, > we will got failure result on running mmi related TCs. (In reply to sku from comment #16) > In addition, FACILITY is not only for CallBarring, but also for SIM PIN/PIN2 > etc... (see 3GPP 27.007 clause 7.4). > Besides CallBarring, we also need to consider not to impact the other > features that FACILITY related to. Yep, still need to deal with test. Thanks for your advise!

Comment on attachment 781223 [details] [diff] [review] v2 Cancel the review until the tests get updated. Sorry for the noise.

These tests cover the code for handling barring all incoming calls through MMI codes, other cases would be the same. I guess it's not needed to replicate the tests for the other cases but It's up to you. Please, let me know.

Comment on attachment 782495 [details] [diff] [review] Part 2: Changes in tests for call barring through MMI codes. Review of attachment 782495 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/system/gonk/tests/test_ril_worker_mmi.js @@ +770,5 @@ > +add_test(function test_sendMMI_call_barring_BAIC_interrogation_voice() { > + let workerhelper = getWorker(); > + let worker = workerhelper.worker; > + > + worker.Buf.readUint32List = function fakeRreadUint32List() { typo: fakeReadUint32List

https://hg.mozilla.org/projects/birch/rev/b9d0b30cbfc4 https://hg.mozilla.org/projects/birch/rev/be963e31c3ee

https://hg.mozilla.org/mozilla-central/rev/b9d0b30cbfc4 https://hg.mozilla.org/mozilla-central/rev/be963e31c3ee

Telefonica QA team could not test this User Storie. We tested with several tests SIMs and supplementary services do not work. We are waiting for a solution.

Rafa, can you provide further information about why these patches are not working for you, please? A RIL log would be useful too. If I am not wrong, jaoo found some issues with TEF test SIMs, as it seems that call barring is forbidden for TEF corporate numbers.

The QA team has the same problem that Jose Antonio. All our movistar SIMs are corporate numbers. We need a comercial SIM to test this user story.

QA team continues with the same problem. We can not test the US with our SIMS. Any updates?

Call barring settings depend on the carrier, I mean the carrier might not allow the user handle this supplementary service. This feature heavily depends on the subscriber's ICC card so I'd would be nice to perform the test with different ICC cards.