869468 - [Bluetooth] Caller number is not displayed on PSA RD45 Carkit

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Bluetooth, defect, P1)

Description

[leo.bugzilla.gecko]

1. Title : [BT/ BT CAR KIT] - Caller number is not displayed on PSA RD45 Carkit
2. Precondition : Pair and connect DUT to CK
3. Tester's Action : receive call.
4. Detailed Symptom (ENG.) : Caller number is displayed on CK except PSA RD45.
5. Frequency Rate : 100%

Caller number is not show the PSA RD45 car kit only.
In the air log, it send CPBS command to phone continuously.
Please check this point.

Thanks.

Comment 1

[leo.bugzilla.gecko]

Attachment: PSA RD45 caller number bug

Comment 2

[leo.bugzilla.gecko]

Attachment: PSA RD45 air log

Comment 3

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Set as IOP bugs.

Comment 4

[Wayne Chang [:wchang]]

Triage 5/8 - compatibility issue, agree not to block unless cert-blocking.

Comment 5

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

In general, b2g phone continuously received CPBS commands are really a bad thing.
But I believe missing caller number is not related to CPBS. As you mentioned only PSA RD45 has this bug. I might need to do experiments for this CK. Can you name which car is this? Which year?

Comment 6

[leo.bugzilla.gecko]

Dear Mozilla Team,

Our tester's comment is,

- Its PSA Peugeot Citroen Car kit, made by Continental . RD45 L3 with SW 3.0.1 RC3 from 25/M/2011

Please refer this info.

Thanks.

Comment 7

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Thanks for CK info, based on my analysis, this looks like CLCC format is invalid.
I guess Continental made an assumption of CLCC direction shall be incoming instead of outgoing.
However, i don't have this similar model to give it a try. But this is the only thing abnormal.

And yes, continuous CPBS commands can cause power consumption problem. I will open another bug to follow up.

Comment 8

[Lukas Blakk [:lsblakk] use ?needinfo]

Seems out of scope for being a blocker on v1.1

Comment 9

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Let's wait Bug 869306 fix first and let leo verify again.

Comment 10

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Open another bug for tracking crazy CPBS inquiry. See bug 870882

Comment 11

[Alex Keybl [:akeybl]]

Comment 8 still stands until it's clear this will impact a large number of CKs and it's also clear that we're doing something wrong.

Comment 12

[leo.bugzilla.gecko]

Dear Mozilla Team,

Please let me know the status of this case.
Do you need any more information or investigation?

Comment 13

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

I reviewed air log and i cannot come out why car kit cannot show caller number. Since we sent "+CLIP" with caller number.  Car kit suppose to get caller number via CLIP command. Another problem indeed we can see a lot of CPBS AT commands and reply ERROR due to we don't support phonebook related AT commands. We could try to reply fake CPBS AT command to give it a try, but I really don't think that's the root cause.
One thing I noticed is that while outgoing call was been performed, car kit actually do query via "CLCC". Maybe this car kit display caller number only based on CLCC? Then my assumption is:
1. CLIP was not sent but PSA RD45 car kit does not display caller number
2. CLCC query was not issued by PSA RD45 car kit because it was queued after multiple error of CPBS.

Comment 14

[leo.bugzilla.gecko]

Dear Shawn,

I found suspect point as below, please check it?

class BluetoothHfpManager::SendRingIndicatorTask : public Task
{
  .............
  if (!mNumber.IsEmpty()) {
      nsAutoCString clipMsg(kHfpCrlf);
      clipMsg.AppendLiteral("+CLIP: \"");
      clipMsg.Append(NS_ConvertUTF16toUTF8(mNumber).get());
      clipMsg.AppendLiteral("\",");
      clipMsg.AppendInt(mType);
      clipMsg.AppendLiteral(kHfpCrlf);
      gBluetoothHfpManager->SendLine(clipMsg.get());
    }

b2g append the kHfpCrlf string in SendLine method.
But clipMsg is appendeded the kHfpCrlf again in first and last line.
Some of carkit check the at command from phone, so I suspect this.

Please check this.
Thanks.

Comment 15

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Your observation is pretty accurate. In fact, I have also review code again and saw RING also with extra CRLF. So if you removed extra CRLF, PSA RD45 can display?

Comment 16

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

re-nominate as leo?

Comment 17

[leo.bugzilla.gecko]

Dear Mozilla Team,

I don't have a RD45 carkit.
But I can send the fixed binary to our qe engineer , so I'll verify this.
If I received the test result, inform to you.

Thanks.

Comment 18

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Sure. Sorry for the hassle. There are some difficulties to verify interoperability bugs here.

Comment 19

[Bruce Huang [:bhuang] (inactive)]

Hello Leo,
Any updates on the test result based on Comment 17?

Comment 20

[leo.bugzilla.gecko]

Dear Mozilla Team,

I still have not received the test results.
If I received the test result, I'll write a comment to here.

Thanks.

Comment 21

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Hi bhuang, if teset result is positive, this is a easy fix. Don't worry about it.

Comment 22

[David Scravaglieri [:scravag]]

Please could you help us to understand if this bug is more generic or if it is specific to PSA RD45 car kit only.

Comment 23

[leo.bugzilla.gecko]

Dear Mozilla Team,

I received the test result is failed.
There seems to be no problem in the air log.
Ring and CIEV command is right but tester said it still don't be displayed.
I suspect "CPBS ERROR" a little, because it received continuously before CIEV.
I attach the air log of fail case and good case, so please check it.

Thanks.

Comment 24

[leo.bugzilla.gecko]

Attachment: Call_number_fail

Comment 25

[leo.bugzilla.gecko]

Attachment: Call_number_is_success

Comment 26

[leo.bugzilla.gecko]

(In reply to David Scravaglieri [:scravag] from comment #22)
> Please could you help us to understand if this bug is more generic or if it
> is specific to PSA RD45 car kit only.

Hi David,

It still seems to be uncommon. However, this is possible to occur in the other car kit.

Thanks.

Comment 27

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Hi leo,
Let's complete patch of bug 870882. I will provide WIP (working in progress) patch tomorrow for you to have a try. I think Bug 870882 is a way to go, since we cannot enumerate any other car kits with the same problem. The worst thing is power consumption here.

Comment 28

[leo.bugzilla.gecko]

Hi Shawn,

OK, I'll request to test again after a bug 870882 is completed.

Thanks.

Comment 29

[Eric Chou [:ericchou] [:echou]]

Quick note. Bug 878672 has been created to solve the problem mentioned in comment 14.

Comment 30

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

I have provided a temporary patch in bug 870882. After checking Log "Call_number_fail" here, I think the patch does not actually been merged into test build. Would you mind help to clarify again? I had tested again with my temporary patch. AT+CPBS=? shall not return "ERROR".
Thanks.

Comment 31

[leo.bugzilla.gecko]

Hi Shawn,

"Call_number_fail.cfa" file is uploaded 05/29, so it is not a air log that merged your patch in bug 870882.
I have tested your patch for CPBS and response is ok when "AT+CPBS=?" is received as your comment. But tester said that call number is not still displayed on PSA RD45 only.

I don't have the PSA Carkit too, so I tested to other carkit.
As a result, AT+CPBS=? is ok, but second command AT+CPBS="ME" cannot handle.

ReceiveSocketData:731 [LGBT_gecko] received Socket message = AT+CPBS?
SendLine:1182 [LGBT_gecko] sending message = +CPBS: "ME",0,256"
SendLine:1182 [LGBT_gecko] sending message = OK
ReceiveSocketData:731 [LGBT_gecko] received Socket message = AT+CPBS="ME"
ReceiveSocketData:1046 [LGBT_gecko] Could't get the value of command [AT+CPBS=]
SendLine:1182 [LGBT_gecko] sending message = OK

I think that fake response can have bad influence on carkit. 
If carkit request the real value, carkit is also possible that the behavior stops itself because invalid reply.

Please check this point.

Thanks.

Comment 32

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Oh. I tested my patch locally, while receiving AT+CPBS="ME", we just reply "OK". After that car kit can send "AT+CPBS?" to get maximum phonebook size. So b2g replys "+CPBS: "ME", 0, 256".
If AT+CPBS="ME"/"DC"/"RC"/"MC", we just reply +CPBS: "ME"/"DC"/"RC"/"MC", 0, 256
I also tested "AT+CPBR=?", b2g will reply "+CPBR: (1-1), 30, 30". No matter what phonebook had been selected, we just reply car kit we have zero records of phonebook. I think the idea is safe but it's hard to say I can cover all the behaviors.
I have seen some old BMW car model is fine with "+CPBR: (1-1), 30, 30"..."OK".

So, yes, there is a concern about call log (MC/DC/RC), because some car kits might record call log by itself. We don't know what will happen if car kits query call log again after call completed. It is possible that car kit expects there should be a call appeared in call log and it does not. The car kit continually send and query call log until condition satisfies. I saw older Audi car kit would update call log immediately after call finished. Maybe this is something you can check further.

Anyway, I agree this call number bug is probably not common issue.
Thanks.

Comment 33

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Due to it's not a common case. As Comment 32 mentioned, even apply "fake reply" patch in bug 870882, problem still happen. We probably test again until PBAP profile was been introduced.