On Tue, Sep 22, 2009 at 7:46 PM, Joerg Reisenweber <[email protected]>wrote:
> [Tom Di 22. September 2009]: > [...] > agree on all that. > [...] > > Btw, you just gave me an idea (about a bug actually) we should normalize > the > > "naked" number we got from a phone call with the prefix info from the > > current network and prefix the contact by using the prefixes from the sim > > card settings. That is the correct thing to do, atm we only normalize > using > > "sim card settings" (actually the settings we set in a file, which in > turn > > should be the same). > > > > Doc, what do you think about the last proposal, any reason why we > shouldn't > > do that? > > -- > > Tom. > > > My original suggestion was to have 3 sets of [IP,CC,NP,AC] tuples, one for > (== > associated to) the stored contacts, one for inbound phonecall numbers, and > maybe one for inbound SMS numbers (as those sometimes are mangled > differently > than the calls). > Usually inbound numbers *always* should be normalized / fully qualified. > But > there's a lot of braindamaged provider network equipment out there - see > Maroc. > > That's sounds a bit like an overkill (having 3) though having two is reasonable! > The contacts settings might be fetched from SIM stored info *once* to fill > a > NULL value in phoneutils.cfg. If there's a setting in config, then don't > touch it. > Ok, but the first time should include some kind of prompt! > Another nice idea is to store a dummy contact to contacts, like > >name: X-MySettingsForPhoneutils_contacts > >number: 00;49;0;911 > That's actually a terrific idea, though I'm not sure this is the correct handling. We should save the normalized number in a opimd column anyway (for fast searching of numbers in opimd, otherwise you can't really create indexes on the columns) so maybe we should have two columns that behave as follows: creating a new "number" column in opimd should cause it to create another column: "normalized-number" (which is needed anyway for searching purposes as mentioned earlier). As mentioned before in this mail, contact normalization should be done using the sim card's prefix info and there fore you'll get a number and a correctly normalized number fields. Now, in the contact creating GUI we should have a "locked/disabled" (i.e grayed out) field that'll show the number the phone thinks there is (i.e the value in the normalized-number column). This way we'll have already normalized numbers in memory (as we do now) and the user's wanted numbers. And this will also let the user know exactly what's wrong and will let him add the prefix (to the non-normalized-number) so it'll be recognized correctly. I hope I explained myself in an understandable manner. If not, please ask. As I think this is the correct way to go (as I said, we should save the normalized-number anyway) > > The inbound call and inbound SMS settings might be fetched from network > info > via some call to modem after registering, as they are network specific > (usually, you never know what maroc carrier does to numbers for roaming > SIMs). If you can't get decent info from network, you might want to > fallback > to a phoneutils.cfg provisioned default. Maybe also have a flag in there to > *override* network info by a setting there in config. > interesting, though I think we need more info about those "crazy" networks. > > cheers > jOERG > > > -- Tom.
_______________________________________________ Shr-User mailing list [email protected] http://lists.shr-project.org/mailman/listinfo/shr-user
