Re: [PATCH] ModemManager: Add GetMsIsdn method to return the phone number



On Monday 23 January 2012, Dan Williams wrote:
> On Sat, 2012-01-21 at 21:28 +0100, Aleksander Morgado wrote:
> > >>> On Thu, 2011-06-30 at 18:18 -0400, Eric Shienbrood wrote:
> > >>>> I can look at doing that. What should we call it? I think MSISDN is
> > >>>> a GSM term. How does GetPhoneNumber() sound?
> > >>> 
> > >>> Hm, old message.  Yes, that method sounds fine.
> > >> 
> > >> Where did this end up?
> > >> 
> > >> Also, AT+CNUM may report a list of numbers, not just one.
> > >> 
> > >> For the 0.6 API I was going to add it as a "PhoneNumbers" property
> > >> (signature 'as') in the Modem interface.
> > >> 
> > >> Anyway, in my own tests, it really didn't report any number, as some
> > >> others noticed. :-/
> > > 
> > > Well IMHO if you are going to get the values from +CNUM, you should
> > > also allow setting of it, would you agree? Essentially it's a list of
> > > SIM contacts, other than that it having a dedicated AT command to
> > > get/set as it's in a different phonebook, there's not really anything
> > > special about it.
> > 
> > Given that we have a "Contacts" interface in the 0.6 API, maybe we could
> > handle own numbers, if retrievable, as any other number in the different
> > available phonebooks.
> 
> CDMA devices always have a command (either AT or QCDM/DIAG) to return
> the MDN since it's stored in the phone and not on a SIM (unless you have
> a RUIM of course, then it's on the RUIM I think).  For the GSM devices,
> it's often programmed as phonebook #0 but that's easy to change, delete,
> or screw up.  So I think there's value in exposing the current phone
> number where we can get it, if we can't then we should probably leave it
> blank.
> 
That seems a reasonable approach to me as long as on GSM you don't return a 
result based on a query to +CNUM. The +CNUM approach to GetOwnNumber is flawed 
but if you really do wish to use it, I think you need to be able to read and 
write the values, so that if it's wrong you can at least correct the entry.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]