Closed Bug 890912 Opened 7 years ago Closed 2 years ago

[User Story][Suplementary Services] [MMI] Handle in-call MMI codes

Categories

(Core :: DOM: Device Interfaces, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

()

RESOLVED INCOMPLETE
tracking-b2g backlog

People

(Reporter: noemi, Unassigned)

References

Details

(Whiteboard: [u=commsapps-user c=dialer p=0], [TEF][UCID:Comms35, FT:comms])

Attachments

(3 files)

Enable the subscriber (calling party or called party) to place an active call on hold to activate another feature, such as placing a call or answering another call. When the other feature is completed, the subscriber can re-establish communications with the held party.

During a call:
1 SEND: retrieve a call previously put on hold
2 SEND: put on hold an active call
3 SEND: put the active call and the held one on a multiconference (merge)
blocking-b2g: --- → koi?
This is the feature of in call MMI command. There are 2 steps to support this feature.

1. Currently, gaia calls dial("1") when user press "1[SEND]" during the call. We should use another API, maybe sendMMI() or create a new one for this purpose. The most important thing is that gecko should notice that it is happened in a call, not a normal sendMMI(). We may encounter some problem between mobileConnection DOM and telephony DOM
  - sendMMI() is a method in mobileConnection.
  - knowing call info is telephony's job

As mentioned in Bug 889737, if we merge dial(), sendMMI() APIs into one and provide a unique API for gaia sending the dialing string to gecko, the above problme could be handled easier.

2. In gecko, we should call proper methods in different cases. For example, hangup(), accept(), switchHolding..().

reference implementation in android
http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/1.5_r4/com/android/internal/telephony/gsm/GSMPhone.java#718
See Also: → 889737
Per comment #0, this is specifically for MMI support, so I changed the bug description.
Summary: [User Story][Suplementary Services] Call Hold support → [User Story][Suplementary Services] [MMI] Call Hold support
Correct one thing.
Currently, no [SEND] key in dialer keypad when during a call.
We need UX's opinion to decide whether we should support in call MMI, or maybe we could achieve the same result by UI menu.
(In reply to Szu-Yu Chen [:aknow] from comment #3)
> Correct one thing.
> Currently, no [SEND] key in dialer keypad when during a call.
> We need UX's opinion to decide whether we should support in call MMI, or
> maybe we could achieve the same result by UI menu.

We already have the call hold support by UI menu. Tapping on the active call, then you will see it.
This is called an incall MMI command although RIL doesn't send any MMI command to modem and so Gaia shouldn't show the MMI sending screen. Therefore I think this should be handled by Dial request itself. 

Also, we would need an option to add a call in the dialer to be able to send these codes when there is an existing call.
(In reply to Anshul from comment #5)
> This is called an incall MMI command although RIL doesn't send any MMI
> command to modem and so Gaia shouldn't show the MMI sending screen.
> Therefore I think this should be handled by Dial request itself. 
> 
> Also, we would need an option to add a call in the dialer to be able to send
> these codes when there is an existing call.

Indeed, just as Aknow said, we need UX and dialer change as well.
Summary: [User Story][Suplementary Services] [MMI] Call Hold support → [User Story][Suplementary Services] [MMI] Handle in-call MMI codes
Just adding dependency with bug 887680 since we need multiconference support for covering the third case included in the description (put the active call and the held one on a multiconference)
Depends on: 887680
(In reply to Szu-Yu Chen [:aknow] from comment #1)
> 1. Currently, gaia calls dial("1") when user press "1[SEND]" during the
> call. We should use another API, maybe sendMMI() or create a new one for
> this purpose.

Maybe I'm not understanding the whole picture here but we could pass the dial string through the dial() function, let gecko know whether it is in a call and if so handle the in-call MMI command. Does it make sense?

AFAIK the dialer app is able to know whether it is in a call. The dialer apps
currently deals with DTMF stuff when the user interacts with the keypad during the call so a change is needed on this as well.

> The most important thing is that gecko should notice that it
> is happened in a call, not a normal sendMMI(). We may encounter some problem
> between mobileConnection DOM and telephony DOM
>   - sendMMI() is a method in mobileConnection.
>   - knowing call info is telephony's job

I guess gecko is able to know whether a call is happening, right?

> As mentioned in Bug 889737, if we merge dial(), sendMMI() APIs into one and
> provide a unique API for gaia sending the dialing string to gecko, the above
> problme could be handled easier.

That would be really good but AFAIK this feature is for v1.2 release and merging
those functions and refactoring the logic underneath could take some time.
 
> 2. In gecko, we should call proper methods in different cases. For example,
> hangup(), accept(), switchHolding..().

If we pass the in-call MMI commands throught the dial() function and once
we know that gecko is in a call we could parse the MMI command and do whatever
needs to be done. Does it make sense?
Assignee: nobody → noef
Whiteboard: [UCID:Comms35, FT:comms, KOI:P1]
blocking-b2g: koi? → koi+
Assignee: noef → nobody
Whiteboard: [UCID:Comms35, FT:comms, KOI:P1] → [TEF][UCID:Comms35, FT:comms, KOI:P1]
I agree with Antonio that we can use the dial request to achieve this. The only problem is that when you are in call there is no option to add another call.
(In reply to Anshul from comment #9)
> I agree with Antonio that we can use the dial request to achieve this. The
> only problem is that when you are in call there is no option to add another
> call.

Yes, this bug already depends on bug 887680 which is the US for that feature.
Whiteboard: [TEF][UCID:Comms35, FT:comms, KOI:P1] → [TEF][UCID:Comms35, FT:comms, KOI:P1][u=commsapps-user c=dialer p=0]
Whiteboard: [TEF][UCID:Comms35, FT:comms, KOI:P1][u=commsapps-user c=dialer p=0] → [TEF][UCID:Comms35, FT:comms, KOI:P1][u=commsapps-user c=dialer p=0][Sprint 2]
Just a note that QA expected to import the test cases from Isabel
Flags: in-moztrap-
Whiteboard: [TEF][UCID:Comms35, FT:comms, KOI:P1][u=commsapps-user c=dialer p=0][Sprint 2] → [u=commsapps-user c=dialer p=0], [TEF][UCID:Comms35, FT:comms, KOI:P1][Sprint 2]
Go for it. We need to discuss about working on this feature before or after unifying both sendMMI() and dial() functions (bug 889737). IHMO we should work on this bug once both functions get unified.
Assignee: nobody → josea.olivera
QA Contact: rafael.marquez
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #12)
> Go for it. We need to discuss about working on this feature before or after
> unifying both sendMMI() and dial() functions (bug 889737). IHMO we should
> work on this bug once both functions get unified.

Hsin-Yi, your feedback is more than welcome. Do you think we should unify both sendMMI() and dial() functions before working on this bug? Thanks!
Flags: needinfo?(htsai)
José,

Unifying dial() and sendMMI() is a large change, and needs more discussion and WebAPI team's review. I'm commenting on bug 889737 to see if we should do this in v1.2.
Flags: needinfo?(htsai)
per comment 14, this is moving to 1.2 nice to have and adding to backlog 891754
Blocks: comms_backlog
No longer blocks: koi-comms
blocking-b2g: koi+ → ---
Whiteboard: [u=commsapps-user c=dialer p=0], [TEF][UCID:Comms35, FT:comms, KOI:P1][Sprint 2] → [u=commsapps-user c=dialer p=0], [TEF][UCID:Comms35, FT:comms, KOI:P2]
(In reply to José Antonio Olivera Ortega [:jaoo] (PTO August 19th till Sept 2nd) from comment #8)
> (In reply to Szu-Yu Chen [:aknow] from comment #1)
> > 1. Currently, gaia calls dial("1") when user press "1[SEND]" during the
> > call. We should use another API, maybe sendMMI() or create a new one for
> > this purpose.
> 
> Maybe I'm not understanding the whole picture here but we could pass the
> dial string through the dial() function, let gecko know whether it is in a
> call and if so handle the in-call MMI command. Does it make sense?
> 
> AFAIK the dialer app is able to know whether it is in a call. The dialer apps
> currently deals with DTMF stuff when the user interacts with the keypad
> during the call so a change is needed on this as well.
> 
> > The most important thing is that gecko should notice that it
> > is happened in a call, not a normal sendMMI(). We may encounter some problem
> > between mobileConnection DOM and telephony DOM
> >   - sendMMI() is a method in mobileConnection.
> >   - knowing call info is telephony's job
> 
> I guess gecko is able to know whether a call is happening, right?
> 
> > As mentioned in Bug 889737, if we merge dial(), sendMMI() APIs into one and
> > provide a unique API for gaia sending the dialing string to gecko, the above
> > problme could be handled easier.
> 
> That would be really good but AFAIK this feature is for v1.2 release and
> merging
> those functions and refactoring the logic underneath could take some time.
>  
> > 2. In gecko, we should call proper methods in different cases. For example,
> > hangup(), accept(), switchHolding..().
> 
> If we pass the in-call MMI commands throught the dial() function and once
> we know that gecko is in a call we could parse the MMI command and do
> whatever
> needs to be done. Does it make sense?
No, unfortunately, without changing the current dial(), it's gonna not work, as dial() returns a TelephonyCall object immediately. If we simply call dial() for in-call MMI, we will have dangling TelephonyCall objects.
I am attaching the visuals needed to implement this based in the 1.2 dialer spec. Please, if you see something missing needinfo me.
THANKS
Whiteboard: [u=commsapps-user c=dialer p=0], [TEF][UCID:Comms35, FT:comms, KOI:P2] → [u=commsapps-user c=dialer p=0], [TEF][UCID:Comms35, FT:comms]
Duplicate of this bug: 910026
Blocks: 960372
No longer blocks: 960372
No longer blocks: b2g--telephony-1.4
reported during v1.3 IOT processes so adding to backlog to be properly prioritized. Thanks!.
blocking-b2g: --- → backlog
No longer blocks: 911055
Assignee: josea.olivera → nobody
QA Contact: rafael.marquez
Depends on: 891242
Hsin-Yi, could you please clarify if bug 1058398 is also blocking this task? Thanks!
Flags: needinfo?(htsai)
Depends on: 1058398
Flags: needinfo?(htsai)
Let me give a clearer dependency here.

Bug 1058398, talking about ussd session, doesn't really block in-call mmi user story but it blocks the gaia work Bug 1031175 which this in-call mmi relies on.
Depends on: 1031175
No longer depends on: 1058398
Depends on: 1093014
Depends on: 1098144
blocking-b2g: backlog → ---
FxOS/Gonk has been removed from the codebase. Mass-invalidating FxOS related Device Interface bugs to clean up the component. 

If I incorrectly invalidated something, please let me know.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INVALID
Bulk correction of resolution of B2G bugs to INCOMPLETE.
Resolution: INVALID → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.