To verify that the AG, upon receiving an origination request from the HF, puts the current call on hold and originates a call to a third party. To verify that the AG performs the actions requested from the HF with respect to call hold and three-way-call handling procedures. Test case : TC_AG_TWC_BV_05_I started - SDP Service record for PTS: 'Handsfree HF' successfully registered - The IUT claims support for the following eSCO LMP packet types: EV3, 2-EV3, - AT: SPP connect succeeded - AT: Service Level Connection established - AT: post SLC command sequence complete - AT: RING - AT: Received +CLIP: "0988095164",129 - AT: Incoming call established - HCI: Audio Connection enabled - AT: WARNING: received redunant +CIEV(call): +CIEV: 2,1 - MTC: Call established by tester - AT: Call terminated - FATAL ERROR (MTC): Call setup by tester failed: callsetup=0 received from AG before notification of successful outgoing call (call=1, callsetup=1). - AT: Call terminated - HCI: Audio Connection disabled - AT: Service Level Connection disabled - MTC: Test case ended Final Verdict : Fail 924 Master 47 ..RING.. Incoming Call/Call progress indication 20 00:00:02.996000 2013/1/10 下午 12:05:08.305000 925 Master 47 ..+CLIP: "0988095164",129.. +CLIP: "0988095164",129 39 00:00:00.000000 2013/1/10 下午 12:05:08.305000 927 Slave 47 ATA. Answer mode 16 00:00:00.031000 2013/1/10 下午 12:05:08.336000 930 Master 47 ..OK.. Success 18 00:00:00.078000 2013/1/10 下午 12:05:08.414000 934 Master 47 ..+CIEV: 2,1.. Call Status indicator's status report 26 00:00:00.359000 2013/1/10 下午 12:05:08.773000 935 Master 47 ..+CIEV: 4,0.. Call Setup indicator's status report 26 00:00:00.000000 2013/1/10 下午 12:05:08.773000 996 Slave 47 AT+BLDN. Set up a voice call to the last phone number dialed 20 00:00:02.605000 2013/1/10 下午 12:05:11.378000 998 Master 47 ..OK.. Success 18 00:00:00.047000 2013/1/10 下午 12:05:11.425000 1,003 Master 47 ..+CIEV: 4,2.. Call Setup indicator's status report 26 00:00:00.124000 2013/1/10 下午 12:05:11.549000 1,008 Master 47 ..+CIEV: 3,1.. Call Held indicator's status report 26 00:00:00.219000 2013/1/10 下午 12:05:11.768000 1,125 Master 47 ..+CIEV: 4,3.. Call Setup indicator's status report 26 00:00:05.179000 2013/1/10 下午 12:05:16.947000 1,308 Master 47 ..+CIEV: 2,1.. Call Status indicator's status report 26 00:00:08.190000 2013/1/10 下午 12:05:25.137000 1,309 Master 47 ..+CIEV: 4,0.. Call Setup indicator's status report 26 00:00:00.000000 2013/1/10 下午 12:05:25.137000 1,466 Slave 47 AT+CHLD=1. Execute "Call hold and multiparty" Command 22 00:00:06.880000 2013/1/10 下午 12:05:32.017000 1,470 Master 47 ..OK.. Success 18 00:00:00.078000 2013/1/10 下午 12:05:32.095000 1,479 Master 47 ..+CIEV: 2,0.. Call Status indicator's status report 26 00:00:00.343000 2013/1/10 下午 12:05:32.438000 1,553 Slave 47 ATD0939835820;. Dial: 0939835820 27 00:00:03.167000 2013/1/10 下午 12:05:35.605000 1,557 Master 47 ..OK.. Dialed Successfully 18 00:00:00.062000 2013/1/10 下午 12:05:35.667000 1,560 Master 47 ..+CIEV: 4,2.. Call Setup indicator's status report 26 00:00:00.078000 2013/1/10 下午 12:05:35.745000 1,677 Master 47 ..+CIEV: 4,3.. Call Setup indicator's status report 26 00:00:05.226000 2013/1/10 下午 12:05:40.971000 1,776 Master 47 ..+CIEV: 2,1.. Call Status indicator's status report 26 00:00:04.446000 2013/1/10 下午 12:05:45.417000 1,777 Master 47 ..+CIEV: 4,0.. Call Setup indicator's status report 26 00:00:00.016000 2013/1/10 下午 12:05:45.433000 1,805 Slave 47 AT+CHUP. Terminate the call 20 00:00:01.154000 2013/1/10 下午 12:05:46.587000 1,809 Master 47 ..OK.. Success 18 00:00:00.078000 2013/1/10 下午 12:05:46.665000 1,818 Master 47 ..+CIEV: 2,0.. Call Status indicator's status report 26 00:00:00.374000 2013/1/10 下午 12:05:47.039000

This shall be fixed with bug 828798.

From the above description, after receiving "AT+CHLD=1", the callheld indicator is not correctly updated.

Since Bug 828798 has been resovled, close this one, too.

Dear Sir, When I use the v1.0.1 to test the TC_AG_TWC_BV_05_I case.I found it still failed. There's the error message.Could you please help us to check it? Test case : TC_AG_TWC_BV_05_I started - SDP Service record for PTS: 'Handsfree HF' successfully registered - The IUT claims support for the following eSCO LMP packet types: EV3, 2-EV3, - AT: SPP connect succeeded - AT: Service Level Connection established - AT: post SLC command sequence complete - AT: RING - AT: Received +CLIP: "13880281851",129 - HCI: Audio Connection enabled - AT: Incoming call established - unexpected second call completion (second outgoing call) - FATAL ERROR (AT): (callsetup=2) received when (call=1), (callheld=1), and there is no second outgoing call process. - FATAL ERROR (AT): callsetup=0 received when there is a held call, and active call, but no previously initiated CHLD action. - HCI: Audio Connection disabled - AT: SPP disconnect succeeded - MTC: Test case ended Final Verdict : Inconclusive

Can you attach cfa file? Thank you.

Hi Sean, After checking the cfa log, the problem you encountered is different from the original problem. My analysis as the following: 1. In the normal case, commands look like: ATA OK +CIEV: 2,1 +CIEV: 4,0 AT+BLDN OK +CIEV: 4,2 +CIEV: 3,1 2. In your case, after AT+BLDN, +CIEV: 3,1 (call held) +CIEV: 4,2 (outgoing call is ongoing) This means modem reports call hold first to bluetooth and reports outgoing call is on-going after that. This is why you see problem. Since there is no second call ongoing, it is impossible to have situation, unless RIL reports incorrectly. 3. Can you help to clarify with your RIL team? Because on unagi with the latest v1.0.1 we cannot hit this problem. And this problem does not look like problem we saw before. This problem needs RIL team's help to check.

Gina, can you confirm Comment 8?

Shawn, I could not open CDs file now. Let me discuss with you tmw morning.

Thanks,Shawn! I will request our RIL team to help to clarify this problem.

(In reply to Gina Yeh [:gyeh] [:ginayeh] from comment #10) > Shawn, I could not open CDs file now. Let me discuss with you tmw morning. typo. s/CDs/cfa/

Hi Shawn, Do you mean that it's the problem about the sequence of the +CIEV: 4,2 and +CIEV: 3,1? Our RIL team told me that the sequence is right.We always process call hold first. When we catch the cfa log use our android phone,we found that the +CIEV: 4,2 and +CIEV: 3,1 are send at the same time in app level code.

Hi Sean, Here is the test result on May 13 build using unagi as reference phone. Test case : TC_AG_TWC_BV_05_I started - SDP Service record for PTS: 'Handsfree HF' successfully registered - The IUT claims support for the following eSCO LMP packet types: EV3, 2-EV3, - The IUT claims support for the following eSCO LMP packet types: EV3, 2-EV3, - AT: SPP connect succeeded - AT: Service Level Connection established - AT: post SLC command sequence complete - AT: RING - AT: Received +CLIP: "0988095164",129 - AT: Incoming call established - HCI: Audio Connection enabled - MTC: Call established by tester - MTC: Call established by tester - MTC: Call established by tester - AT: Call terminated - MTC: Call disabled by IUT - HCI: Audio Connection disabled - AT: Service Level Connection disabled - MTC: Test case ended Final Verdict : Pass

Hi Sean, Attached daily build test result on unagi. It can pass smoothly.

To make things clear, I will Mozilla RIL not commercial which can pass the test case.

(In reply to Shawn Huang from comment #8) > Hi Sean, > After checking the cfa log, the problem you encountered is different from > the original problem. > My analysis as the following: > 1. In the normal case, commands look like: > ATA > OK > +CIEV: 2,1 > +CIEV: 4,0 > AT+BLDN > OK > +CIEV: 4,2 > +CIEV: 3,1 > > 2. In your case, after AT+BLDN, > +CIEV: 3,1 (call held) > +CIEV: 4,2 (outgoing call is ongoing) > > This means modem reports call hold first to bluetooth and reports > outgoing call is on-going after that. This is why you see problem. Since > there is no second call ongoing, > it is impossible to have situation, unless RIL reports incorrectly. I don’t understand what you are talking about when there is no second call (BT just dialed the call so there is an outgoing call). As I understand the scenario is that there is an active call already and BT HF tries to dial another call. As soon as RIL receives the dial request, it tries to hold the existing call and notifies the BT that the existing call is on hold and once RIL says that the existing call is held, dials the second call and the RIL notifies BT about the second outgoing call. BT HF already knows that it dialed a call so why is it an impossible situation when we reported that the existing call is on hold? RIL always reports call in order of their indexes. So telephony receives response from RIL the call index 1 would be on hold and the call index 2 would be dialing. [0193]< GET_CURRENT_CALLS { id=1,HOLDING,toa=129,norm,mo,als=0,voc,noevp,8586517026,cli=0,name='',0 id=2,DIALING,toa=129,norm,mo,als=0,voc,noevp,8582045364,cli=0,name='',} And so commercial RIL will always report call hold request 1st and then call dialing request later. This issue needs to be fixed in BT code itself. I think this is a poor assumption in BT code that they expect the outgoing call to be notified first and then a held call when the operations in RIL happen the other way around. Moreover this is exactly how Android behaves. > > 3. Can you help to clarify with your RIL team? Because on unagi with the > latest v1.0.1 we cannot hit this problem. And this problem does not look > like problem we saw before. > This problem needs RIL team's help to check.

Hi Sean, Just to clarify with HFP 1.5 spec. In the original HFP 1.5 spec, 4.22.2 Three Way Calls – Third Party Call Placed from the HF. Figure 4.26: Three way call handling when the third party call is placed from the HF. After AT command "ATD", +CIEV: (callheld=1), +CIEV: (callsetup = 2). This behavior matches that what the problem that Sean mentioned. So basically, nothing is wrong here if using Bluetooth HFP 1.5 spec. If you checked errta 2459 (Incorrect sequence of indicators update), HFP 1.5 errata had proposed. https://www.bluetooth.org/errata/errata_view.cfm?errata_id=2459 See attachment: https://www.bluetooth.org/errata/comment_view.cfm?comment_id=5074

Hi Shawn, I have checked errta 2459,it looks like it's the problem about PTS. And could you please tell me the version number of your PTS? My PTS is v.4.6.0.7.Just for your information. Thanks.

My PTS version is 4.7. Can you talk with BQB lab for this problem? Even on your platform, we're spec compatible for sure. Do you agree my point of view?

(In reply to Shawn Huang from comment #20) > My PTS version is 4.7. Can you talk with BQB lab for this problem? Even on > your platform, we're spec compatible for sure. Do you agree my point of view? I mean the original HFP 1.5.

Hi Shawn, You could be right,I think so. We will let BQB lab to test our phone,and talk with them about this problem. Thank you very much.