1041865 - B2G RIL: Seek vacancy for contact field in second phonebook set if the first pbs doesn't have sufficient space.

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: RIL, defect)

Description

[shawn ku [:sku]]

Attachment: Cannot export contact to SIM with email field on a specific sim.

For a specific SIM, when user try to export acontact to SIM with email field. We always got error - NoFreeRecordFound USIM field email.


// Log snippet.
07-14 09:14:39.954   159   694 I Gecko   : RIL Worker: [0] Received chrome message {"requestId":"id{f1b77965-9c04-4331-9428-187889ec0a62}","contactType":"adn","contact":{"alphaId":"AAAA  BBB ","number":"111111111","anr":["2222222"],"email":"[e-mail]","contactId":"898601128110048334445"},"pin2":null,"rilMessageClientId":0,"rilMessageToken":20,"rilMessageType":"updateICCContact"}
07-14 09:14:39.955   159   694 I Gecko   : RIL Worker: [0] Update ICC Contact {"alphaId":"AAAA  BBB ","number":"111111111","anr":["2222222"],"email":"[e-mail]","contactId":"898601128110048334445","pbrIndex":0,"recordId":5}
07-14 09:14:50.213   159   694 I Gecko   : RIL Worker: [0] NoFreeRecordFound
07-14 09:14:50.214   159   694 I Gecko   : RIL Worker: [0] NoFreeRecordFound USIM field email
07-14 09:14:50.215   159   159 I Gecko   : -*- RadioInterface[0]: Received message from worker: {"requestId":"id{f1b77965-9c04-4331-9428-187889ec0a62}","contactType":"adn","contact":{"alphaId":"AAAA  BBB ","number":"111111111","anr":["2222222"],"email":"[e-mail]","contactId":"898601128110048334445","pbrIndex":0,"recordId":5},"pin2":null,"rilMessageClientId":0,"rilMessageToken":20,"rilMessageType":"updateICCContact","errorMsg":"NoFreeRecordFound"}
07-14 09:14:50.218   824   824 I Gecko   : -*- RILContentHelper: Received message 'RIL:UpdateIccContact': {"clientId":0,"data":{"requestId":"id{f1b77965-9c04-4331-9428-187889ec0a62}","contactType":"adn","contact":{"alphaId":"AAAA  BBB ","number":"111111111","anr":["2222222"],"email":"[e-mail]","contactId":"898601128110048334445","pbrIndex":0,"recordId":5},"pin2":null,"rilMessageClientId":0,"rilMessageToken":20,"rilMessageType":"updateICCContact","errorMsg":"NoFreeRecordFound"}}

Comment 1

[shawn ku [:sku]]

Hi Edgar:
 Could you please help check this issue first?

Thanks!!
Shawn

Comment 2

[shawn ku [:sku]]

// EF_PBR structure
// 07-14 09:14:40.028   485   515 D use-Rlog/RLOG-AT: +CRSM: 144, 0, "621E82054221004C0283024F30A5038001718A01058B036F0605800200988800"
A8 1E
   C0 03 
      4F 3A 11 // ADN, SFI: 0x11
   C4 03 
      4F 5B 15 // ANR, SFI: 0x15
   C6 03 
      4F 52 14 // GRP, SFI: 0x14
   C5 03
      4F 42 13 // PBC, SFI: 0x13
   C9 03
      4F 62 18 // UID, SFI: 0x18
   C1 03
      4F 32 16 // IAP, SFI: 0x16

A9 05
   CA 03
      4F 72 19 // Email, SFI: 19

AA 14
   C2 03
      4F 4A 0A // EXT1, SFI: 0x0A
   C7 03 
      4F 4B 0B // AAS, SFI: 0x0B
   C8 03
      4F 4C 0C // GAS, SFI: 0x0C
   CB 03
      4F 4F 0D // CCP1, SFI: 0x0D

FFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

Comment 3

[shawn ku [:sku]]

Two PBR records:
07-14 09:14:40.196   485   515 D use-Rlog/RLOG-AT: +CRSM: 144, 0, "A81EC0034F3901C4034F5A05C6034F5104C5034F4103C9034F6108C1034F3106A905CA034F7109AA14C2034F4A0AC7034F4B0BC8034F4C0CCB034F4F0DFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"

A8 1E
   C0 03 4F39 01
   C4 03 4F5A 05
   C6 03 4F51 04
   C5 03 4F41 03
   C9 03 4F61 08
   C1 03 4F31 06
A9 05
   CA 03 4F71 09 // EMAIL, SFI: 09
AA 14 
   C2 03 4F4A 0A
   C7 03 4F4B 0B
   C8 03 4F4C 0C
   CB 03 4F4F 0D
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
---
07-14 09:14:40.301   485   515 D use-Rlog/RLOG-AT: +CRSM: 144, 0, "A81EC0034F3A11C4034F5B15C6034F5214C5034F4213C9034F6218C1034F3216A905CA034F7219AA14C2034F4A0AC7034F4B0BC8034F4C0CCB034F4F0DFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF"

A8 1E
   C0 03 4F3A 11
   C4 03 4F5B 15
   C6 03 4F52 14
   C5 03 4F42 13
   C9 03 4F62 18
   C1 03 4F32 16
A9 05
   CA 03 4F72 19 // EMAIL, SFI: 19
AA 14
   C2 03 4F4A 0A
   C7 03 4F4B 0B
   C8 03 4F4C 0C
   CB 03 4F4F 0D
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

Comment 4

[shawn ku [:sku]]

As we can see in log, the 4F71 indicates:
Record length : 40
# of Record: 100

And, we can see 100 records are all full on 4F71.
however, EMAIL is with A9 type (see 3GPP 31.102, Table 4.1: Phone Book Reference file Constructed Tags)

We should jump to 4F72 to seek if any vancancy for EMAIL address.

---
07-14 09:14:40.784   485   498 D use-Rlog/RLOG-AT: AT> AT+CRSM=192,20337,0,0,0,,"7f105f3a"
07-14 09:14:40.849   485   515 D use-Rlog/RLOG-AT: +CRSM: 144, 0, "621F8205422100286483024F71A5038001718A01058B036F060380020FA0880148"

62 1F
   82 05 // File Descriptor
      42 21 00 28 64 // 00 28: record length (40),  number of record (100)
   83 02 // File Identifier
      4F 71
   A5 03 // Proprietary Template
      80 01 71
   8A 01 // Life Cycle Status
      05
   8B 03 // Security Attribute - Reference Format
      6F 06 03
   80 02 // File Size - Data
      0F A0 // File Size : 4000
   88 01 SFI Support
      48

Comment 5

[Edgar Chen [:edgar]]

(In reply to shawn ku [:sku] (OOO 7/17 ~ 7/31) from comment #4)
> As we can see in log, the 4F71 indicates:
> Record length : 40
> # of Record: 100
> 
> And, we can see 100 records are all full on 4F71.
> however, EMAIL is with A9 type (see 3GPP 31.102, Table 4.1: Phone Book
> Reference file Constructed Tags)
> 
> We should jump to 4F72 to seek if any vancancy for EMAIL address.

To be more precise:
No only seek vacancy for email in second phonebook set, whole contact's records need to move to second phonebook set, too.

> 
> ---
> 07-14 09:14:40.784   485   498 D use-Rlog/RLOG-AT: AT>
> AT+CRSM=192,20337,0,0,0,,"7f105f3a"
> 07-14 09:14:40.849   485   515 D use-Rlog/RLOG-AT: +CRSM: 144, 0,
> "621F8205422100286483024F71A5038001718A01058B036F060380020FA0880148"
> 
> 62 1F
>    82 05 // File Descriptor
>       42 21 00 28 64 // 00 28: record length (40),  number of record (100)
>    83 02 // File Identifier
>       4F 71
>    A5 03 // Proprietary Template
>       80 01 71
>    8A 01 // Life Cycle Status
>       05
>    8B 03 // Security Attribute - Reference Format
>       6F 06 03
>    80 02 // File Size - Data
>       0F A0 // File Size : 4000
>    88 01 SFI Support
>       48

Comment 6

[shawn ku [:sku]]

(In reply to Edgar Chen [:edgar][:echen] from comment #5)
> (In reply to shawn ku [:sku] (OOO 7/17 ~ 7/31) from comment #4)
> > As we can see in log, the 4F71 indicates:
> > Record length : 40
> > # of Record: 100
> > 
> > And, we can see 100 records are all full on 4F71.
> > however, EMAIL is with A9 type (see 3GPP 31.102, Table 4.1: Phone Book
> > Reference file Constructed Tags)
> > 
> > We should jump to 4F72 to seek if any vancancy for EMAIL address.
> 
> To be more precise:
> No only seek vacancy for email in second phonebook set, whole contact's
> records need to move to second phonebook set, too.

Agree, and thanks for clarifying this.

> 
> > 
> > ---
> > 07-14 09:14:40.784   485   498 D use-Rlog/RLOG-AT: AT>
> > AT+CRSM=192,20337,0,0,0,,"7f105f3a"
> > 07-14 09:14:40.849   485   515 D use-Rlog/RLOG-AT: +CRSM: 144, 0,
> > "621F8205422100286483024F71A5038001718A01058B036F060380020FA0880148"
> > 
> > 62 1F
> >    82 05 // File Descriptor
> >       42 21 00 28 64 // 00 28: record length (40),  number of record (100)
> >    83 02 // File Identifier
> >       4F 71
> >    A5 03 // Proprietary Template
> >       80 01 71
> >    8A 01 // Life Cycle Status
> >       05
> >    8B 03 // Security Attribute - Reference Format
> >       6F 06 03
> >    80 02 // File Size - Data
> >       0F A0 // File Size : 4000
> >    88 01 SFI Support
> >       48

Comment 7

[Edgar Chen [:edgar]]

bug 1194149 provide a solution for insufficient contact field. Let's see if there is still a strong requirement to keep contact field as much as possible. Thank you.

Comment 8

[BMO Automation]

Firefox OS is not being worked on