pgravel Reporter
	Description • 9 years ago

This is a similar issue reported in bug 1159958, but here we have one held call and one alerting call.

The test case is defined in 3GPP TS 51.010

Scenario :
1. Make a phone call and hold it
2. Dial a second call, let it go into the alerting state (ringing on dialed phone)
3. Dial '4' (Explicit call transfer in-call mmi code), get error message  “Cannot make a call, if  you are already dialing, please hang up first.”

It looks like the call is being blocked because the UI still considers an "alerting" call to be in the same state as "dialing".

	shawn ku [:sku]
	Comment 1 • 9 years ago

Ni myself for issue tracking.

	shawn ku [:sku]
	Comment 2 • 9 years ago

Hi Gabriele,
 Could you please help check if there is anything missed regarding bug 1159958?


There are two cases that ECT can be triggered.
3GPP TS 23.091
4.2.2 ECT (both calls answered)
4.2.3 ECT (one call answered, the other alerting)

---
3GPP 51.010 
31.13.1.6 Explicit Call Transfer invocation, expiry of T(ECT)
...

Test purpose
To test that the MS invokes explicit call transfer between an active held call and an alerting call by sending a FACILITY message with the correct invoke component, and returns both calls to their original states on expiry of T(ECT).

	Johan Lorenzo [:jlorenzo]
	Comment 3 • 9 years ago

Comms triage: Certification blocker on a feature implemented in 2.2

	Gabriele Svelto [:gsvelto] (PTO)
	Comment 4 • 9 years ago

From what I can tell there's nothing in gaia that's preventing the additional call from being made. I wonder if this is because of bug 1161905. Hsin-Yi can you shed more light on this issue?

	pgravel Reporter
	Comment 5 • 9 years ago

It's not due to bug 1161905. The dial request seems to get stopped in telephony.cpp's Telephony::DialInternal[1]


[1] http://mxr.mozilla.org/mozilla-central/source/dom/telephony/Telephony.cpp#230

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

(In reply to pgravel from comment #5)
> It's not due to bug 1161905. The dial request seems to get stopped in
> telephony.cpp's Telephony::DialInternal[1]
> 
> 
> [1]
> http://mxr.mozilla.org/mozilla-central/source/dom/telephony/Telephony.cpp#230

Thanks Phil. It looks we need to make the if conditions correct and proper.

	Hsin-Yi Tsai (she/her) [:hsinyi] Assignee
	Comment 8 • 9 years ago

Hi Phil,
Please help verify if the patch solves the issue. Thanks.

	pgravel Reporter
	Comment 9 • 9 years ago

Patch works for me, thanks!

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

Comment on attachment 8612207 [details] [diff] [review]
[m-c] [v2.2] 0001-Bug-1168515-GCF-test-case-31.13.1.4-failure-Explicit.patch

Hi Aknow,
This patch removes the improper check in Telephony.cpp. Mind taking a look? Thank you.

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

Comment on attachment 8612207 [details] [diff] [review]
[m-c] [v2.2] 0001-Bug-1168515-GCF-test-case-31.13.1.4-failure-Explicit.patch

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

Good. Thank you.

	Pulsebot
	Comment 12 • 9 years ago

https://hg.mozilla.org/integration/b2g-inbound/rev/535fbd392978

	Dylan Oliver [:doliver]
	Comment 13 • 9 years ago

Hi Hsin-Yi, just a reminder to request b2g37 approval for this blocker.

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

(In reply to Dylan Oliver [:doliver] from comment #13)
> Hi Hsin-Yi, just a reminder to request b2g37 approval for this blocker.

Thanks for reminding. I should wait for the patch in m-c first before asking for b2g37 approval. I will do that afterwards.

	Hsin-Yi Tsai (she/her) [:hsinyi] Assignee
	Comment 15 • 9 years ago

Hi Ryan,
My patch has been pushed to b2g-inbound a couple days but haven't been merged in to m-c. As this is a 2.2 blocker that the schedule is tight, could you kindly help check? Thank you.

	Ryan VanderMeulen [:RyanVM]
	Comment 16 • 9 years ago

It was merged yesterday, but apparently the bug wasn't marked. Note that for future reference, hg changeset hashes are immutable, so you can verify yourself that a given cset is on mozilla-central by altering the b2g-inbound link to point to m-c instead.
https://hg.mozilla.org/mozilla-central/rev/535fbd392978

	Hsin-Yi Tsai (she/her) [:hsinyi] Assignee
	Comment 17 • 9 years ago

(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #16)
> It was merged yesterday, but apparently the bug wasn't marked. Note that for
> future reference, hg changeset hashes are immutable, so you can verify
> yourself that a given cset is on mozilla-central by altering the b2g-inbound
> link to point to m-c instead.
> https://hg.mozilla.org/mozilla-central/rev/535fbd392978

Great to learn, thanks for the assistance again :)

	Hsin-Yi Tsai (she/her) [:hsinyi] Assignee
	Comment 18 • 9 years ago

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): GCF test case 31.13.1.4 failure : Explicit call transfer failure between held call and alerting call
User impact if declined: GCF failed, and user cannot explicitly transfers a held call and an alerting call
Testing completed: yes, confirmed by partner
Risk to taking this patch (and alternatives if risky): low because we removed a function which was separate 
String or UUID changes made by this patch:

	Ryan VanderMeulen [:RyanVM]
	Comment 19 • 9 years ago

https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/4eea7e9b74da