Closed Bug 1069862 Opened 5 years ago Closed 5 years ago

MozMobileConnection.getCallBarringOption() with a specific serviceClass doesn't work on some operator

Categories

(Firefox OS Graveyard :: RIL, defect)

x86_64
Linux
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
2.1 S6 (10oct)

People

(Reporter: aknow, Assigned: aknow)

References

Details

Attachments

(1 file, 1 obsolete file)

Consider to have a workaround solution to cover the case.

In gecko implementation, we could always use serviceClass=0 in ril request no matter what is given from api user. Then process the ril response to return the result for that serviceClass asked by user.
Summary: Get call barring options with specific serviceClass doesn't work on some operator → MozMobileConnection.getCallBarringOption() with a specific serviceClass doesn't work on some operator
(In reply to Szu-Yu Chen [:aknow] from comment #0)
> Consider to have a workaround solution to cover the case.
> 
> In gecko implementation, we could always use serviceClass=0 in ril request
> no matter what is given from api user. Then process the ril response to
> return the result for that serviceClass asked by user.

I rethink about it... As title, this is operator-specific but I doubt how we could have a solution/workaround for all operators on reference phones. As we don't even have a clear definition of the meaning of serviceClass 0, I am concerned whether serviceClass 0 works for all operators. Could it possibly break the original behavior that is working on specifying a certain serviceClass? Unless we have more ideas about the semantic of serviceClass 0, I tend to close this bug as WONTFIX :(
(In reply to Hsin-Yi Tsai (OOO Sep. 22) [:hsinyi] from comment #1)
> (In reply to Szu-Yu Chen [:aknow] from comment #0)
> > Consider to have a workaround solution to cover the case.
> > 
> > In gecko implementation, we could always use serviceClass=0 in ril request
> > no matter what is given from api user. Then process the ril response to
> > return the result for that serviceClass asked by user.
> 
> I rethink about it... As title, this is operator-specific but I doubt how we
> could have a solution/workaround for all operators on reference phones. As
> we don't even have a clear definition of the meaning of serviceClass 0, I am
> concerned whether serviceClass 0 works for all operators. Could it possibly
> break the original behavior that is working on specifying a certain
> serviceClass? Unless we have more ideas about the semantic of serviceClass
> 0, I tend to close this bug as WONTFIX :(

In current design, MMI code like "*#33#" will be implemented by using serviceClass 0. That means if serviceClass 0 doesn't work for all operators, we should also get the problem when sending this MMI code.
(In reply to Szu-Yu Chen [:aknow] from comment #2)
> (In reply to Hsin-Yi Tsai (OOO Sep. 22) [:hsinyi] from comment #1)
> > (In reply to Szu-Yu Chen [:aknow] from comment #0)
> > > Consider to have a workaround solution to cover the case.
> > > 
> > > In gecko implementation, we could always use serviceClass=0 in ril request
> > > no matter what is given from api user. Then process the ril response to
> > > return the result for that serviceClass asked by user.
> > 
> > I rethink about it... As title, this is operator-specific but I doubt how we
> > could have a solution/workaround for all operators on reference phones. As
> > we don't even have a clear definition of the meaning of serviceClass 0, I am
> > concerned whether serviceClass 0 works for all operators. Could it possibly
> > break the original behavior that is working on specifying a certain
> > serviceClass? Unless we have more ideas about the semantic of serviceClass
> > 0, I tend to close this bug as WONTFIX :(
> 
> In current design, MMI code like "*#33#" will be implemented by using
> serviceClass 0. That means if serviceClass 0 doesn't work for all operators,
> we should also get the problem when sending this MMI code.

Oh, yup... thanks for the reminding. Then I am fine with this workaround, thank you Aknow.
Attachment #8495736 - Flags: review?(htsai)
Comment on attachment 8495736 [details] [diff] [review]
Use serviceClass 0 to query callbarring option

Review of attachment 8495736 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good, thank you.
Attachment #8495736 - Flags: review?(htsai) → review+
Keywords: checkin-needed
Attachment #8495736 - Attachment is obsolete: true
https://hg.mozilla.org/mozilla-central/rev/0c22e43c9e77
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.1 S6 (10oct)
You need to log in before you can comment on or make changes to this bug.