Noemí Freire (:noemi) Reporter
	Description • 11 years ago

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)

	Szu-Yu Chen [:aknow] (inactive)
	Comment 1 • 11 years ago

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

	Hsin-Yi Tsai (she/her) [:hsinyi]
	Comment 2 • 11 years ago

Per comment #0, this is specifically for MMI support, so I changed the bug description.

	Szu-Yu Chen [:aknow] (inactive)
	Comment 3 • 11 years ago

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.

	Hsin-Yi Tsai (she/her) [:hsinyi]
	Comment 4 • 11 years ago

(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.

	Anshul
	Comment 5 • 11 years ago

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.

	Hsin-Yi Tsai (she/her) [:hsinyi]
	Comment 6 • 11 years ago

(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.

	Noemí Freire (:noemi) Reporter
	Comment 7 • 11 years ago

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)

	José Antonio Olivera Ortega [:jaoo]
	Comment 8 • 11 years ago

(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?

	Anshul
	Comment 9 • 11 years ago

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.

	José Antonio Olivera Ortega [:jaoo]
	Comment 10 • 11 years ago

(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.

	Al Tsai [:atsai]
	Comment 11 • 11 years ago

Just a note that QA expected to import the test cases from Isabel

	José Antonio Olivera Ortega [:jaoo]
	Comment 12 • 11 years ago

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.

	José Antonio Olivera Ortega [:jaoo]
	Comment 13 • 11 years ago

(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!

	Hsin-Yi Tsai (she/her) [:hsinyi]
	Comment 14 • 11 years ago

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.

	Joe Cheng [:jcheng] (please needinfo)
	Comment 15 • 11 years ago

per comment 14, this is moving to 1.2 nice to have and adding to backlog 891754

	Hsin-Yi Tsai (she/her) [:hsinyi]
	Comment 16 • 11 years ago

(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.

	Victoria Gerchinhoren [:vicky]
	Comment 17 • 11 years ago

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

	Noemí Freire (:noemi) Reporter
	Comment 22 • 11 years ago

reported during v1.3 IOT processes so adding to backlog to be properly prioritized. Thanks!.

	Beatriz Rodríguez [:brg]
	Comment 23 • 10 years ago

Hsin-Yi, could you please clarify if bug 1058398 is also blocking this task? Thanks!

	Hsin-Yi Tsai (she/her) [:hsinyi]
	Comment 24 • 10 years ago

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.

	Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)
	Comment 25 • 7 years ago

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.

	Firefox Bug Husbandry Bot
	Comment 26 • 7 years ago

Bulk correction of resolution of B2G bugs to INCOMPLETE.