As per 3GPP 23.041, only a subset of messages can be toggled by the user aka MMI. Currently, the ril.cellbroadcast.enabled allows the user to toggle all cell broadcast messages which is not allowed. Further, the operator_variant.xml allows the operator to set a range which is treated as MMI - which it is not. The simple fix is to remove the setting from the Settings app and RIL and base activation exclusively on the presence of ranges to be enabled. The better fix is to also add settings for individual MMI-allowed ranges to the settings app but we already have a bug for this.

Per https://bugzilla.mozilla.org/show_bug.cgi?id=874796#c8 , "All channels - emergency and non-emergency channels should be switched on/off with this single option as per agreement with Operator."

It's based on a user story bug 874796 and it does its own job well. You can always leave "ril.cellbroadcast.disabled" false to achieve what originally defined in 23.041. ni Wilfred if he knows the full context of this request.

This requirement came out of specific operator asks and required for passing approval tests.

(In reply to Wilfred Mathanaraj [:WDM] from comment #3) > This requirement came out of specific operator asks and required for passing > approval tests. And yet is not spec compliant. Although they said they want all ranges disabled, I would bet what they actually want is to disable is the range of messages that they are interested in as in their network it would be equivalent. Certain ranges should be not user disabled such as ETWS but as support for those wasn't there when their devices launched we can assume they don't care if those ranges are enabled or not. Operators and OEMs do all kinds of interesting things but the reference code provided by Mozilla should be spec compliant. Any OEM/operator customizations can be done by them or in separate branches as this makes the code base applicable to the largest number of customers and support is easier to track.

(In reply to Michael Schwartz [:m4] from comment #4) > (In reply to Wilfred Mathanaraj [:WDM] from comment #3) > > This requirement came out of specific operator asks and required for passing > > approval tests. > > And yet is not spec compliant. Thanks for the comment, Michael! I agree that mozilla reference code should be spec compliant, and we are willing to do so. However, what I am not really clear is how our implementation isn't spec compliant. Could you please elaborate? The search list we set consists 4 parts: CBMI, CBMID, CBMIR and MMI. About the part of MMI, our implementation [1] refers to 3GPP TS 23.041 v11.2.0 section 9.4.1.2.2. Our code checks if the search list falls within the range of "not settable by MMI" and discards the wrong range. ETWS, as an example, isn't falling into the category of "not settable by MMI" so our code allows the setting. But it looks like you have a different interpretation -- the legal MMI range should be those explicitly marked as "settable by MMI", instead of the exclusion from the "not settable by MMI" ones. For me, I don't see any statement defining which is the correct interpretation, blacklist or whitelist. It would be great help if you could point us the statement so that we can make sure we don't misunderstand a certain case. Thanks again :) [1] http://dxr.mozilla.org/mozilla-central/source/dom/system/gonk/ril_consts.js?from=ril_consts.js&case=true#1275 > Although they said they want all ranges > disabled, I would bet what they actually want is to disable is the range of > messages that they are interested in as in their network it would be > equivalent. Certain ranges should be not user disabled such as ETWS but as > support for those wasn't there when their devices launched we can assume > they don't care if those ranges are enabled or not. > > Operators and OEMs do all kinds of interesting things but the reference code > provided by Mozilla should be spec compliant. Agree! :) > Any OEM/operator > customizations can be done by them or in separate branches as this makes the > code base applicable to the largest number of customers and support is > easier to track.

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #5) Hi Hsin-Yi, Thanks for your well thought out reply. You're right that Gecko ensures that MMI is within the user settable ranges but the "ril.cellbroadcast.disabled" setting doesn't just disable those ranges but disables all ranges - even the non toggleable ones. Further, that check doesn't make sense because the searchlist is populated by operator variant - not the user/MMI. So, we need to: a) Remove the CB disabled setting as we have no concept of MMI ranges so we have nothing to disable or, b) Create a new settings for operator variant ranges and MMI ranges There is an option C which would be disabling only the MMI settable ranges but then the operator has no easy way for customization so I r- that idea. All ears for options though...

(In reply to Michael Schwartz [:m4] from comment #6) > (In reply to Hsin-Yi Tsai [:hsinyi] from comment #5) > > Hi Hsin-Yi, > > Thanks for your well thought out reply. You're right that Gecko ensures > that MMI is within the user settable ranges but the > "ril.cellbroadcast.disabled" setting doesn't just disable those ranges but > disables all ranges - even the non toggleable ones. > You said all ranges, all defined in the spec? Hmmm, I thought "RIL_REQUEST_GSM_SMS_BROADCAST_ACTIVATION" would enable/disable only the ranges we set in searchList, but seems it's not the case? If we just want to disable the settable ranges, the implementation would need to remove them from the searchlist? If above is correct, then it's very interesting that what the use case "RIL_REQUEST_GSM_SMS_BROADCAST_ACTIVATION" is for. Only for turning on, never off? > Further, that check doesn't make sense because the searchlist is populated > by operator variant - not the user/MMI. > I understand now the searchlist is coming from operator variant, not input from user. But, from the spec point of view, I don't see the guideline of differentiating operator and user inputs when they are within a valid and settable range, e.g. 0 ~ 999. The implementation at least doesn't conflict the spec. Also, the request is coming from operator and the behaviour is confirmed by them, I'd like to have the reconfirmation before we take any of the following options. > So, we need to: > a) Remove the CB disabled setting as we have no concept of MMI ranges so we > have nothing to disable or, > b) Create a new settings for operator variant ranges and MMI ranges > > There is an option C which would be disabling only the MMI settable ranges > but then the operator has no easy way for customization so I r- that idea. > All ears for options though...