Wrong phone number detection via TAPI | developer.brewmp.com Wrong phone number detection via TAPI | developer.brewmp.com

Developer

Wrong phone number detection via TAPI

Forums:

ITAPI interface contains method ITAPI_GetStatus which can be used to obtain some phone-related information, including MobileID. In most cases, MobileID is actually user’s phone number and it’s very handy, since it can be used as unique user ID or allows to track for example purchases made by this user or send back an SMS message or any other cool things. However, not all phones returns phone number, some of them return just some weird set of digits (however, that’s interesting, area code is always correct). See attached screenshot of table with results.

In particular, we have problems with Motorola C343, LG VX4600, Kyocera KX414 and LG VX6000.

Can anyone comment this behaviour (kind of weird, I think) or add to this table?

In most cases , It is the MIN ( Mobile Identification Number) which u get in szMobileID
which is located at (szMobileID +5 ) the Previous 5 bytes generally contain area code.
On which device did u get the actual phone number instead of MIN ?
Reply
Regards

In most cases , It is the MIN ( Mobile Identification Number) which u get in szMobileID
which is located at (szMobileID +5 ) the Previous 5 bytes generally contain area code.
On which device did u get the actual phone number instead of MIN ?
Reply
Regards

Check screenshot that I've attached in my original post, for most handsets actual phone number is returned. As far as I know MIN (mobile identification number) is not required to be equal to MDN (mobile directory number, i.e. actual phone number), but I previously thought (based on experience with Australian carrier) that it's depends from carrier, not from handset.
But as I said, most devices return actual phone number (MDN), that's why it's sad that we have to put workarounds for several exception handsets.

Check screenshot that I've attached in my original post, for most handsets actual phone number is returned. As far as I know MIN (mobile identification number) is not required to be equal to MDN (mobile directory number, i.e. actual phone number), but I previously thought (based on experience with Australian carrier) that it's depends from carrier, not from handset.
But as I said, most devices return actual phone number (MDN), that's why it's sad that we have to put workarounds for several exception handsets.

Alex ,
I just got a word from one person working for the carriers, that it actually is dependent on the implementation by carriers. I dont know whether thats true for all of them.
But at least for this carrier , I confirmed that they get MIN always and not MDN.
Can u just add one more column as to what carrier u got the data for each of the phones ?
And I think in 2.0 ideally it should give MIN only.
Let us know if u get any more info on this..
Regards

Alex ,
I just got a word from one person working for the carriers, that it actually is dependent on the implementation by carriers. I dont know whether thats true for all of them.
But at least for this carrier , I confirmed that they get MIN always and not MDN.
Can u just add one more column as to what carrier u got the data for each of the phones ?
And I think in 2.0 ideally it should give MIN only.
Let us know if u get any more info on this..
Regards

That's all for Verizon Wireless. Actually, that's puzzles me a lot, that on the same carrier some handsets returns MIN which is equal to MDN and some not.

That's all for Verizon Wireless. Actually, that's puzzles me a lot, that on the same carrier some handsets returns MIN which is equal to MDN and some not.

Yes thats wierd..
Have u got any info abt this from the verizon guys ?
What are they saying abt this ?
Also just a wild guess is that , since MDN is not available in 2.0 , these guys may be trying to use szMobile ID to throw MDN for applications to handle for newer handsets .... Just a guess.
Tell me if u get any word from verizon guys abt this..
Regards

Yes thats wierd..
Have u got any info abt this from the verizon guys ?
What are they saying abt this ?
Also just a wild guess is that , since MDN is not available in 2.0 , these guys may be trying to use szMobile ID to throw MDN for applications to handle for newer handsets .... Just a guess.
Tell me if u get any word from verizon guys abt this..
Regards

Thank u max for that piece of information
Regards

Thank u max for that piece of information
Regards

mohlendo wrote:https://brewx.qualcomm.com/bws/content/gi/common/appseng/en/developerfaq...
Max, using this functionality requires setting MDN CLASSID dependency in a MIF-file. Setting this dependancy will result in failure to submit this package to the NSTL, since they don't have version 2.1 on theis submission page and the system says that we have unresolved dependency in our MIF file.
How do you suggest to submit applications that use this functionality to NSTL?

mohlendo wrote:https://brewx.qualcomm.com/bws/content/gi/common/appseng/en/developerfaq...
Max, using this functionality requires setting MDN CLASSID dependency in a MIF-file. Setting this dependancy will result in failure to submit this package to the NSTL, since they don't have version 2.1 on theis submission page and the system says that we have unresolved dependency in our MIF file.
How do you suggest to submit applications that use this functionality to NSTL?

Just to add another handset to the list:
Samsung A890 does NOT report the correct phone number (tested on Verizon Wireless). In fact it's even the wrong area code.

Just to add another handset to the list:
Samsung A890 does NOT report the correct phone number (tested on Verizon Wireless). In fact it's even the wrong area code.