Closed Bug 927764 Opened 11 years ago Closed 11 years ago

[B2G][DSDS][User Story] Selection of SIMs for MO voice/USSD/SS, MO Text, MO Data call

Categories

(Firefox OS Graveyard :: RIL, defect)

x86
All
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: khu, Unassigned)

References

()

Details

(Keywords: feature, Whiteboard: [ucid:DSDS2, FT:RIL, 1.3:p1] [L0])

As a user, under Dual SIM settings menu, I should be able to select individual subscriptions to be used for MO Voice/USSD/SS, MO Text, MO Data call. Also, there should be a menu for configuring subscriptions per SIM card.
blocking-b2g: --- → 1.3+
Depends on: 814625, 921400, 921991
Depends on: 854326
Depends on: 927812
Blocks: 926345
Acceptance Criteria: 1) As a user, under ""configure subscriptions"" menu, I should be able to select the SIMs (and subscriptions within) from available options.e.g. The user can have 2 SIMs from 2 different providers. e.g. AT&T, Verizon. Each SIM can have more than 1 subscription. In case of dual SIM, The user should be able to select 2 of the total subscriptions available e.g. AT&T SIM (subscription 1 & 2). Another example is AT&T SIM (subscription1) & Verizon SIM (subscription 2). Note: The Above is based on guidance from chipset/modem provider. If there are questions, we can check with them for clarity. However I think we can assume for most emerging markets 1 SIM would have subscriptions from 1 carrier. 2) There should be a way to select a SIM card for each of these services: MO Voice/USSD/SS, MO Text, MO Data call.
Hi Sandip, Could we have Qualcomm to clarify 1) acceptance criteria?
Flags: needinfo?(skamat)
I also have concerns about criteria 1). I have raised this in [1]. I doubt if this is a feasible criteria. Per my understanding, it's not possible that two subscriptions in a single sim card are available at a time. Use could switch between the two subscriptions through STK, but those are not dual-standby. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=918533#c5
(In reply to Hsin-Yi Tsai [:hsinyi] from comment #3) > I also have concerns about criteria 1). I have raised this in [1]. > > I doubt if this is a feasible criteria. Per my understanding, it's not > possible that two subscriptions in a single sim card are available at a > time. These are based on the capabilities of what the chipset can support. Anshul, can you help clarify these further?
Flags: needinfo?(skamat) → needinfo?(anshulj)
(In reply to Sandip Kamat from comment #4) > (In reply to Hsin-Yi Tsai [:hsinyi] from comment #3) > > I also have concerns about criteria 1). I have raised this in [1]. > > > > I doubt if this is a feasible criteria. Per my understanding, it's not > > possible that two subscriptions in a single sim card are available at a > > time. Two subscriptions on the same card can be available just like how two subscriptions on two separate cards can be available and we have seen such cards, although it is a test card. However I think that for all practical purposes this is a not a common case and so we might not need to worry about it, or at least not right now. > > These are based on the capabilities of what the chipset can support. Anshul, > can you help clarify these further?
Flags: needinfo?(anshulj)
(In reply to Anshul from comment #5) > (In reply to Sandip Kamat from comment #4) > > (In reply to Hsin-Yi Tsai [:hsinyi] from comment #3) > > > I also have concerns about criteria 1). I have raised this in [1]. > > > > > > I doubt if this is a feasible criteria. Per my understanding, it's not > > > possible that two subscriptions in a single sim card are available at a > > > time. > Two subscriptions on the same card can be available just like how two > subscriptions on two separate cards can be available and we have seen such > cards, although it is a test card. However I think that for all practical > purposes this is a not a common case and so we might not need to worry about > it, or at least not right now. > Great, I also think now is not the time to take care of this case. Sandip, could we adjust the acceptance criteria per Anshul's suggestion? Thank you. > > > > These are based on the capabilities of what the chipset can support. Anshul, > > can you help clarify these further?
Flags: needinfo?(skamat)
When we are implementing WebTelephony API, we encounter a problem: Will we allow the default(primary) SIM to change when the phone is in-call, no matter the phone is busy with primary SIM or not? I would suggest 'disallowing' otherwise there could be various timing issues and error-prone. Ask for UX's comments. Thanks!
Flags: needinfo?(cawang)
Copying our email discussion -- Anshul, Here is how I am defining the terms internally Primary SIM = the one which the user chooses to make outgoing calls. Active SIM = The one on traffic channel (in call). It could be primary (outgoing, incoming) or non-primary (incoming). I have ensured these are consistent in the G-doc, let me know if you see exceptions. [Anshul] Want to confirm that these terms are specific to voice subscription and not data. If data and voice default to different SIMs then if the data call is up the modem will be active on the data SIM. Also, the fact that 1 SIM can have multiple subscriptions is causing a lot of confusion in engg. For 1.3 timeframe, I am thinking to allow people use SIM and subscription interchangeably for now. [Anshul] Sounds good.
Flags: needinfo?(skamat)
Updated Acceptance Criteria for simplifying a bit for now. (Assume 1 carrier on 1 SIM for target markets) 1) As a user, under "configure subscriptions" menu, I should be able to select the SIMs for each service (Assume 1 carrier on 1 SIM) 2) There should be a way to select a SIM card for each of these services: MO Voice/USSD/SS, MO Text, MO Data call.
(In reply to Hsin-Yi Tsai [:hsinyi] from comment #7) > When we are implementing WebTelephony API, we encounter a problem: Will we > allow the default(primary) SIM to change when the phone is in-call, no > matter the phone is busy with primary SIM or not? > > I would suggest 'disallowing' otherwise there could be various timing issues > and error-prone. Ask for UX's comments. Thanks! Hi Hsin-Yi, I agree with you that we shouldn't allow users to switch settings while the phone is in "in-call" status. Thanks!
Flags: needinfo?(cawang)
(In reply to Sandip Kamat from comment #9) > Updated Acceptance Criteria for simplifying a bit for now. (Assume 1 carrier > on 1 SIM for target markets) > > 1) As a user, under "configure subscriptions" menu, I should be able to > select the SIMs for each service (Assume 1 carrier on 1 SIM) Hi Sandip,I would like to confirm with you again for this item. From UX spec v0.3, there is no extra setting for subscription configuration. And we are focus on 1 carrier on 1 SIM now, what other expectation you still have for this item or we can skip this from this user story? > 2) There should be a way to select a SIM card for each of these services: MO > Voice/USSD/SS, MO Text, MO Data call.
Flags: needinfo?(skamat)
Sandip, where are we at with respect to this user story. Without this user story we will have hard time testing basic DSDS. We are targeting 15th November for basic DSDS and would need this user story to be working by that time.
provide moztrap link of this user story.
(In reply to Enpei from comment #11) > (In reply to Sandip Kamat from comment #9) > > Updated Acceptance Criteria for simplifying a bit for now. (Assume 1 carrier > > on 1 SIM for target markets) > > > > 1) As a user, under "configure subscriptions" menu, I should be able to > > select the SIMs for each service (Assume 1 carrier on 1 SIM) > Hi Sandip,I would like to confirm with you again for this item. From UX spec > v0.3, there is no extra setting for subscription configuration. And we are > focus on 1 carrier on 1 SIM now, what other expectation you still have for > this item or we can skip this from this user story? The current UX spec looks okay to me with the simplification of 1 carrier per SIM. > > > 2) There should be a way to select a SIM card for each of these services: MO > > Voice/USSD/SS, MO Text, MO Data call.
Flags: needinfo?(skamat)
(In reply to Anshul from comment #12) > Sandip, where are we at with respect to this user story. Without this user > story we will have hard time testing basic DSDS. We are targeting 15th > November for basic DSDS and would need this user story to be working by that > time. Ken, please update?
Flags: needinfo?(kchang)
(In reply to Sandip Kamat from comment #15) > (In reply to Anshul from comment #12) > > Sandip, where are we at with respect to this user story. Without this user > > story we will have hard time testing basic DSDS. We are targeting 15th > > November for basic DSDS and would need this user story to be working by that > > time. > > Ken, please update? The implementations of Gecko side will be done in this week. And The implementations of Gaia is ongoing. I don't think Comms and gaia system team can finish all those implementations before 15th Nov. Since the original target for them is 6th Dec. But you can talk with them.
Flags: needinfo?(kchang)
Whiteboard: [ucid:ucid:DSDS2, FT:RIL, 1.3:p1] → [ucid:ucid:DSDS2, FT:RIL, 1.3:p1] [L0]
Blocks: 932731
Remove blocking-b2g flag from User Story bugs. Use whiteboard to indicate what FxOS version we target.
blocking-b2g: 1.3+ → ---
Whiteboard: [ucid:ucid:DSDS2, FT:RIL, 1.3:p1] [L0] → [ucid:ucid:DSDS2, FT:RIL, 1.3:p2] [L0]
Keywords: feature
Blocks: 938433
Whiteboard: [ucid:ucid:DSDS2, FT:RIL, 1.3:p2] [L0] → [ucid:ucid:DSDS2, FT:RIL, 1.3:p1] [L0]
Whiteboard: [ucid:ucid:DSDS2, FT:RIL, 1.3:p1] [L0] → [ucid:DSDS2, FT:RIL, 1.3:p1] [L0]
Depends on: 933203
Blocks: b2g-dsds-1.4
No longer blocks: b2g-dsds-1.4
Sorry. According to https://bugzilla.mozilla.org/show_bug.cgi?id=933203#c11 933203 isn't a blocker for this bug. And close this user story to ask verification.
Status: NEW → RESOLVED
Closed: 11 years ago
No longer depends on: 933203
Resolution: --- → FIXED
Depends on: 928297, 941310, 943215, 944223
Hi Enpei, I saw you found some critical bugs. Should we reopen this user story?
Flags: needinfo?(echu)
(In reply to Ken Chang from comment #19) > Hi Enpei, I saw you found some critical bugs. Should we reopen this user > story? Yes, those are blocking some of my test cases but not totally avoid testing being executed, so I would like to keep the status without reopening the user story. Feel free to let me know if we would like to change the way we track this bug. Thank you.
Flags: needinfo?(echu)
Depends on: 944303
No longer depends on: 944223
Verified on Fugu Fugu Gaia ee25b0e45649d2955f340ce4f71ad55712dd0fab Gecko 913cf2b92845441c9578787362ddad6f2ac15df6 BuildID 20140121095108 Version 28.0a2 No blocking issue for this user story.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.