Closed Bug 903275 Opened 11 years ago Closed 11 years ago

[zffos1.1][dialer] No incoming call inside call log after closing caller ID display service

Categories

(Firefox OS Graveyard :: Gaia::Dialer, defect)

Product:
Firefox OS Graveyard
Component:
Gaia::Dialer
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking-b2g:leo+)

Status:
RESOLVED INVALID
Project Flags:
blocking-b2g leo+

People

(Reporter: gerard-majax, Unassigned)

References

Details

(Whiteboard: [u=commsapps-user c=dialer p=0])

Attachments

(5 files)

2013-08-09-14-32-58.png
90.07 KB, image/png
Details
detailed operator message-2013-08-09-14-33-03.png
113.47 KB, image/png
Details
sim card service2013-08-09-14-33-21.png
54.75 KB, image/png
Details
detailed caller id display function 2013-08-09-14-33-31.png
41.69 KB, image/png
Details
operator service on settings-2013-08-09-16-53-30.png
58.81 KB, image/png
Details 
This is a followup of bug 900848, since I first misundertood it and found/fixed a related issue. So we will discuss and fix the original issue here. Bug 900848 was leo+, this one should bee, too.
Taken from bug 900848#c26:

« what i mean is that a service "来电显示" that i translate as "caller id service" which the Operator close it, then UE(User Equipment) can't get the phone number from every incoming call.not blacklist or whitelist. »

STR from original comment:

1、close caller ID display service.
2、have a call , reject or answer.
3、check call log


Actual results:

there is no incoming call log.


Expected results:

there is a incoming call log.

Zhang, I'm not sure to correctly understand your sentence « which the Operator close it, then UE(User Equipment) can't get the phone number from every incoming call ». What is the operator here ? Is it the mobile network ? Or the user of the phone ?
Flags: needinfo?(zhang.wei38)
Here is what I just tried:

 - Calling Firefox OS (Inari) from an Android phone with caller id set to hidden number
 - On the Inari, refusing the call
 - Checking the call log: I have an entry, missing the "withheld number" label (as described in bug 900848)
 - Placing another call from another phone with caller id set to network default. This network defaults to showing the caller id.
 - On the Inari, refusing the call
 - Checking call log: I have two entries, the latest one containing the correct phone number.

This was on uptodate master. I'm going to cross check on v1-train. In the mean time, if you could also:
 - cross check on master on your side
 - provide us with references (device, carrier, etc.)
 - check that you are using the same source base as us
I can't reproduce on Keon v1.1 build of july 24th (buildid 20130724051151).
And I can't reproduce on a build of mine, which is gecko-18-hd (bfb440d5c23e7c7a97eb906136808f0d2b783d73) and the gaia v1-train you pointed at (45f6a739b09292e16717fb21003386c914ca29c2)
And nothing after changing to chinese or taiwanese locale.
thank you for doing this! the key may be the misunderstanding of "caller id service".I don't know whether there is such service abroad. This service is bind with the sim card and is controlled by the mobile network operator, user can cancel this service by sending request to the operator through the STK application(or usim card application), such as China Mobile Monternet.I cancel this service by the steps as followed, i don't know whether you can reproduce. By the way, some sim card do not support this service :
  1、insert a sim card and restart the phone.
  2、waiting a minute and unlock, you can find an dialog with the content of operator message.
  3、click the "ok" button, then it will start the setting app automaticly.
  4、select the item of "caller ID display" and display another interface.
  5、select the item of "cancel caller ID display" and hint send a sms to the operator.
  6、receive a sms and show that you have cancelled this service successfully.

I will attach some screenshots!
Flags: needinfo?(zhang.wei38)
Attached image 2013-08-09-14-32-58.png — 
operator message
detailed operator message
start setting app and show the sim card function as list
detailed caller id display function
Depends on: 900848
No longer depends on: 900848
(In reply to zhangwei from comment #6)
> thank you for doing this! the key may be the misunderstanding of "caller id
> service".I don't know whether there is such service abroad. This service is
> bind with the sim card and is controlled by the mobile network operator,
> user can cancel this service by sending request to the operator through the
> STK application(or usim card application), such as China Mobile Monternet.I
> cancel this service by the steps as followed, i don't know whether you can
> reproduce. By the way, some sim card do not support this service :
>   1、insert a sim card and restart the phone.
>   2、waiting a minute and unlock, you can find an dialog with the content of
> operator message.
>   3、click the "ok" button, then it will start the setting app automaticly.
>   4、select the item of "caller ID display" and display another interface.
>   5、select the item of "cancel caller ID display" and hint send a sms to the
> operator.
>   6、receive a sms and show that you have cancelled this service successfully.
> 
> I will attach some screenshots!

Thanks !

As far as I can tell, Caller ID control here is handled through RIL CLIR command, I'm not sure it goes through the STK.

Now that you precised this, it means I need to tweak the caller id on the Firefox OS side, which was not clear at all previously, since v1-train has no support for playing with the caller id in settings. I wonder if this might have an impact on the behavior.
Blocks: 899451
No longer blocks: 899451
Axel, see comment 0.
Blocks: 899451
Change to leo+ because this bug is derived from from 900848.
blocking-b2g: leo? → leo+
operator service on settings on firefox os. On android, the service is an application named Monternet.
(In reply to zhangwei from comment #14)
> Created attachment 788033 [details]
> operator service on settings-2013-08-09-16-53-30.png
> 
> operator service on settings on firefox os. On android, the service is an
> application named Monternet.

Okay thanks for this. I've just retried with a master build that has support for Caller ID in Settings app. After hiding my number, calling from Android, I can't reproduce.
do you mean that after answered the call or missed the incoming call, start dialer app and switch to the call log page, then you can find a call log record? but i can't find a call log record in our environment, which is this bug report.
(In reply to zhangwei from comment #16)
> do you mean that after answered the call or missed the incoming call, start
> dialer app and switch to the call log page, then you can find a call log
> record? but i can't find a call log record in our environment, which is this
> bug report.

Yes, this is the behavior that I'm having: I get an entry in the call log.
could you tell me you build version, I want to test in my environment, just tell me the version of your gaia and gecko.
(In reply to zhangwei from comment #18)
> could you tell me you build version, I want to test in my environment, just
> tell me the version of your gaia and gecko.

I just tested with the same releases that you pointed at, from pvtbuild.
the version of gecko is not the same as i provided, my version is 
70e86369a5c5068a8c4934b4af2fca65d70340de

please check, thank you.
87dc9a5e61417227aaca15646c5b51362c823f51 from pvtbuilds of yesterday, still not reproducing.
I can not find the the above-mentioned tag of "bfb440d5c23e7c7a97eb906136808f0d2b783d73"  in my current branch but can find it in another branch. When i check out to that branch, it can not build successfully, so i want to know whether you can find the tag of "70e86369a5c5068a8c4934b4af2fca65d70340de", if you can find this tag, could you fall back to this tag and reproduce.
Hi Alexandre,

I tried the build provided by ZTE and I can reproduce the case. What I did are
1. Caller disable the "display number" service on the caller's phone setting
2. Call ZTE v1.1 phone, the number shown on ZTE phone will become "Withheld Number" instead of the real phone number. 
3. Go to call history to see the log but cannot see this withheld number shown in the call log list.

ZTE's build is based on gaia 8/7 build, could you have a try again?

Ivan Tsay
(In reply to Ivan Tsay (:ITsay) from comment #24)
> Hi Alexandre,
> 
> I tried the build provided by ZTE and I can reproduce the case. What I did
> are
> 1. Caller disable the "display number" service on the caller's phone setting
> 2. Call ZTE v1.1 phone, the number shown on ZTE phone will become "Withheld
> Number" instead of the real phone number. 
> 3. Go to call history to see the log but cannot see this withheld number
> shown in the call log list.
> 
> ZTE's build is based on gaia 8/7 build, could you have a try again?
> 
> Ivan Tsay

8/7 ? It's 7th of august, right ?

I've already spent several hours trying to reproduce it with our builds, especially the  pvtbuild from last thursday (so it should match the build you are talking about), without success. Plus, I'd like screenshots of the call log, to make sure we are in sync about the "cannot see" thing.

Could you try to reproduce it with builds that are on pvtbuilds ?
I'll check with Tim to see if any engineer in Taipei can help me. I am not familiar with using pvtbuild.
(In reply to Ivan Tsay (:ITsay) from comment #26)
> I'll check with Tim to see if any engineer in Taipei can help me. I am not
> familiar with using pvtbuild.

Hi Ivan, it's reproducable on ZTE oepn with their release build. The build is not rooted yet so we could not flash our code into the device for verifying issue. Could you please help with asking them to provide the rooted image for their latest build? Thanks.
(In reply to Steve Chung [:steveck] from comment #27)
> (In reply to Ivan Tsay (:ITsay) from comment #26)
> > I'll check with Tim to see if any engineer in Taipei can help me. I am not
> > familiar with using pvtbuild.
> 
> Hi Ivan, it's reproducable on ZTE oepn with their release build. The build
> is not rooted yet so we could not flash our code into the device for
> verifying issue. Could you please help with asking them to provide the
> rooted image for their latest build? Thanks.

I've sent you the rooted build info through email. Please check it out.
After some brief investigation, the some error occurred while querying the key from call log db(dialerGroups database). It only reproduced when qurey withheld number with comercial gecko. The error message: DataError: Data provided to an operation does not meet requirements. The problem seems not related to gaia because using same gaia version(master) with different gecko build will have different result, but the database should be mantained in gaia... Need more time to verify if there got any difference between databases.
Hi Ivan, the root cause for this issue is because of the web API mozTelephony changed in their gecko. The imcoming withheld number should be handled as empty string, but they return the null object in this case. They might need to modidy their gecko to make this scenario work. Since I take PTO until next Mon, you can refer RIL member (maybe yoshi) for more details. Thanks.
Ok, I did some test. As Steve said, bug 888592 moves Telephony WebAPI to webIDL that causes some object type changes. 

Before bug 888592 (when we were using .xpidl), 'typeof' telephonyCall.number was object even the definition said it should be string. After bug 888592 (using .webidl), 'typeof' telephonyCall.number is a real string as expected. So I think updating gecko to the latest revision should help our partner solve this problem. And I guess this problem has been existing for a long time...
(In reply to Hsin-Yi Tsai [:hsinyi] from comment #31)
> Ok, I did some test. As Steve said, bug 888592 moves Telephony WebAPI to
> webIDL that causes some object type changes. 
> 
> Before bug 888592 (when we were using .xpidl), 'typeof' telephonyCall.number
> was object even the definition said it should be string. After bug 888592
> (using .webidl), 'typeof' telephonyCall.number is a real string as expected.
> So I think updating gecko to the latest revision should help our partner
> solve this problem. And I guess this problem has been existing for a long
> time...

Unfortunately, bug 888592 is landed in m-c only, and it's a framework change. If we want to uplift that patch, we will need more and more other framework patches uplifted as well that would be quite large and risky. It's not appropriate to uplift it to v1-train at this moment IMHO.
Hi Hsin-yi,

The weird thing is that it does not happen on v1.0.1. I will further check it with Gaia to see if the way of handling telephony object is changed after 1.0.1.
(In reply to Ivan Tsay (:ITsay) from comment #33)
> Hi Hsin-yi,
> 
> The weird thing is that it does not happen on v1.0.1. I will further check
> it with Gaia to see if the way of handling telephony object is changed after
> 1.0.1.

Hi guys,

Sorry about my previous comments. I seemed to use wrong branch (my personal working branch with my own changes...) for previous tests. 

I tested it again with git gecko master branch and gaia master branch. No matter with the revision before or after bug 888592, I CANNOT reproduce the issue. I got 'empty string' and had a call history there. Sorry about the noise. 

I have no idea about Steve's comment #30, i.e. API changes in partner's gecko. Will try to investigate the version in comment #20, see if I could get some clue there.
Hi Wei,

Could you please ask your engineer or Qalcomm engineer to see if anything was modified in the following files. What we found is the object that holds the empty string become "null" so that the call is not logged in the history. These files are related to the flow of logging the call history. If there is a call without ID, the string should be an empty string. If the call has the number, the string should holds the number.

1) nsIDOMTelephonyCall.idl  (DOMString number)
2) Telephony.cpp
3) TelephonyCall.cpp

Ivan Tsay
Flags: needinfo?(zhang.wei38)
I tried these files from modification history to find clues but have no result, Please elaborate on what you have found, thank you!
Flags: needinfo?(zhang.wei38)
Hi Wei,

Thank you for the confirm. Another possibility is the integration of Qualcomm's RIL. Have you had the chance to ask qualcomm regarding the RIL integration about this part. I suspect it may be relate because we cannot reproduce it anyhow from our build. Mostly we use our own RIL to double confirm if case is related to the RIL integration. With your build, we can debug it up to gecko level but RIL part debug should go to Qualcomm. I am thinking it can be possible that the call from RIL does not set this information properly all along to the UI level in the flow when the call ID is empty. Could you help to check it again.
Flags: needinfo?(zhang.wei38)
Assignee: nobody → lissyx+mozillians
Whiteboard: [u=commsapps-user c=dialer p=0]
Flags: needinfo?(zhang.wei38)
Hi Wei,

May I know if this issue still exist or if you have chance to check if the information is not properly set from RIL when receiving a incoming call? Let me know if you need help from Mozilla after checking the RIL part.

Ivan Tsay
Flags: needinfo?(zhang.wei38)
the bug still exist and our engineers are checking, we will present the result as soon as we get.
Flags: needinfo?(zhang.wei38)
Thank you, Zhang Wei.
we have found that the call id passed from Qualcomm's RIL to gecko is "\0"(empty string), not null.The default value of Call ID is '\0', if we change the default value to non-empty, such as "123", we can get the call log, so we doubt the judge code about the call id may be wrong.
Hi Ivan,
  It seems that Gecko or Gaia can't handle "\0". In my understanding, the workflow should be:
1. Gecko or Gaia or someother service in the firefox sends RIL_REQUEST to get the phone number.
2. Then RILD will response this request by RIL_RESPONSE with the string "\0"
3. Gecko or Gaia should parse retured string.

So could you help to point where in the codes to handle the RIL_RESPONSE?
De-assigning myself since I won't be able to address it this week.
Assignee: lissyx+mozillians → nobody
(In reply to zhangbaisheng from comment #42)
> Hi Ivan,
>   It seems that Gecko or Gaia can't handle "\0". In my understanding, the
> workflow should be:
> 1. Gecko or Gaia or someother service in the firefox sends RIL_REQUEST to
> get the phone number.
> 2. Then RILD will response this request by RIL_RESPONSE with the string "\0"
> 3. Gecko or Gaia should parse retured string.
> 
> So could you help to point where in the codes to handle the RIL_RESPONSE?

You should check this with people who know the Gecko RIL code. Vicamo or Yoshi would be of good help !
Flags: needinfo?(vyang)
Flags: needinfo?(allstars.chh)
(In reply to zhangbaisheng from comment #42)
> Hi Ivan,
>   It seems that Gecko or Gaia can't handle "\0". In my understanding, the
> workflow should be:
> 1. Gecko or Gaia or someother service in the firefox sends RIL_REQUEST to
> get the phone number.
> 2. Then RILD will response this request by RIL_RESPONSE with the string "\0"
> 3. Gecko or Gaia should parse retured string.
> 
> So could you help to point where in the codes to handle the RIL_RESPONSE?

Hi, 

MozRIL gets the phone number of a call from rild in [1]. And in [2], you can find the details for parsing the string. It shows an empty string "" returns when the string length is 0.

[1] http://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/ril_worker.js#4743
[2] http://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/worker_buf.js#278
Flags: needinfo?(vyang)
Flags: needinfo?(allstars.chh)
Hi Hsin-yi,
   How to print log in the ril_worker.js file, we try dump function to print the log on the above-mentioned position, but it does not work.
(In reply to zhangwei from comment #46)
> Hi Hsin-yi,
>    How to print log in the ril_worker.js file, we try dump function to print
> the log on the above-mentioned position, but it does not work.

set DEBUG to true in ril_consts.js
Hi,
  We have located the fault, which is in Qualcomm's part. when the call id is a empty string, it assign a null to the call id.
  This issue can be closed, thank you!
Thank you for the investigation !
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Change to resolve invalid and add POVB in white board to indicate we don't change anything in our build for this bug. It is part of vendor's build.
Resolution: FIXED → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: