Closed
Bug 881846
Opened 12 years ago
Closed 12 years ago
[leo-pre-iot-br] CLIR by #31# not working
Categories
(Firefox OS Graveyard :: Gaia::Dialer, defect)
Tracking
(blocking-b2g:-)
RESOLVED
WORKSFORME
blocking-b2g | - |
People
(Reporter: dpalomino, Assigned: leo.bugzilla.gecko)
References
Details
(Whiteboard: [leo-pre-iot-br], [u=commsapps-user c=dialer p=0] )
Attachments
(1 file)
152.16 KB,
text/plain
|
Details |
Device: leo
buildid: 20130529095707 (brazilian variant)
build 06/07:
Gecko revision : 08e8a7bbebec924c24a5187a3c0b2ef1ef6d08da
Gaia revision : e2346ca0297f40547e64a7eebc4bd2e4a4cdaf86
Commercial RIL : AU_LINUX_GECKO_ICS_STRAWBERRY.01.01.00.019.115
It's not possible to use CLIR with #31# prefix with Vivo numbers:
1. Under Vivo coverage in Brazil
2. Dial #31#011999xxxxxx (xxxxxx any six-digit number)
3. Error message (no valid number) appears
logcat attached
Assignee | ||
Comment 1•12 years ago
|
||
According to the log, network is not attached.
D/CALL_TRACKER_QC_B2G( 144): Service state STATE_OUT_OF_SERVICE, isEmergencyOnly 1, isEmergencyNumber 0, isDialEmergency 0
Thanks.
Assignee | ||
Comment 2•12 years ago
|
||
Please re-test when network is attached.
Assignee | ||
Comment 4•12 years ago
|
||
This case is happened in OUT_OF_SERVICE state and I'll change the status to resolved.
Please do not hesitate to contact me if you have a question.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
Reporter | ||
Comment 5•12 years ago
|
||
Hi,
Also reproduced when it's attached. Sorry about the missunderstanding regarding the logs, was related to another issue.
Bug reopened.
Status: RESOLVED → REOPENED
Flags: needinfo?(dpv)
Resolution: WONTFIX → ---
Updated•12 years ago
|
Assignee: nobody → leo.bugzilla.gecko
Assignee | ||
Comment 6•12 years ago
|
||
You mean, CLIR didn't work even if network is normal.
Please update the log with IN-SERVICE, not OUT-OUT-OF-SERVICE.
Flags: needinfo?(dpv)
Assignee | ||
Comment 7•12 years ago
|
||
Any updates?
For debugging, the log is needed in IN-SERVICE state.
Updated•12 years ago
|
Whiteboard: [leo-pre-iot-br] → [leo-pre-iot-br], [u=commsapps-user c=dialer p=0]
Assignee | ||
Updated•12 years ago
|
blocking-b2g: leo+ → leo?
Comment 8•12 years ago
|
||
Besides functionality, what is the number expected in callLog?
#31#xxxxxxxxx or xxxxxxxxx only?
Assignee | ||
Comment 9•12 years ago
|
||
On the caller device?
xxxxxxxx number is only displayed.
Comment 10•12 years ago
|
||
(In reply to leo.bugzilla.gecko from comment #9)
> On the caller device?
> xxxxxxxx number is only displayed.
Ooops, what I mean is
if user dial #31#123456789, remote will show withhled number for sure,
and, what is the number to store in callLog after call end?
Let me decribe symptom more clearly.
1. A device call B with dial string #31#1234567890
2. B recieve an incoming call with "Withheld number"
3. B hangup the call
4. store #31#1234567890 (or 1234567890) into callLog?
Assignee | ||
Comment 11•12 years ago
|
||
It should be stored 1234567890 only.
You can compare it with any android phone if you have one.
It is working properly on FFOS devices now, so you don't have to worry about stored number in callLog.
![]() |
||
Updated•12 years ago
|
Flags: in-moztrap?
Assignee | ||
Comment 12•12 years ago
|
||
Our team tested this CLIR in brazil and CLIR behavior is normal.
Please re-test with latest version.
If there is related to any other issue, please make sure what it is.
If not, please close this issue.
(In reply to David Palomino [:dpv] from comment #5)
> Hi, Also reproduced when it's attached. Sorry about the missunderstanding
> regarding the logs, was related to another issue.
Flags: needinfo?(dcoloma)
Reporter | ||
Comment 13•12 years ago
|
||
Hi,
Thanks for the info (and sorry for the delayed answer, I was on PTO these last two weeks).
We've retested this in Spain and is working, but we should retest it also in Brazil (just in case). May we ask to vendor colleagues to do a quick tests in Brazil through your colleagues there?
Thanks!
David
Flags: needinfo?(dpv)
Flags: needinfo?(dcoloma)
Comment 14•12 years ago
|
||
(In reply to David Palomino [:dpv] from comment #13)
> We've retested this in Spain and is working, but we should retest it also in
> Brazil (just in case). May we ask to vendor colleagues to do a quick tests
> in Brazil through your colleagues there?
Please renominate if this is found to be an issue.
blocking-b2g: leo? → -
![]() |
||
Updated•12 years ago
|
Flags: in-moztrap? → in-moztrap-
Assignee | ||
Comment 15•12 years ago
|
||
David,
Any update?
If CLIR works normally in BZ, please close this case.
Flags: needinfo?(dpv)
Reporter | ||
Comment 16•12 years ago
|
||
Hi,
We still don't have devices available for testing in BZ. Can you ask to your colleagues in SP to retest it?
Thks!
David
Flags: needinfo?(dpv)
Assignee | ||
Comment 17•12 years ago
|
||
Dear David,
Our colleagues have already tested CLIR in both Spain and Brazil.
In there, CLIR works normally. (Please refer Comment 12.)
Thanks,
Joy.
Flags: needinfo?(dpv)
Reporter | ||
Comment 18•12 years ago
|
||
Hi, ok, sorry for the missunderstanding. Then I think we can close this issue as WFM.
Thks!
David
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Flags: needinfo?(dpv)
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•