>>-1- After pairing operation we ask the user to dial his phone number. We will assume that this first dialed number is the user phone number
Could you re-explain this point to me please, I'm not sure what you mean. Do you mean that the BT device has a screen and a keypad and the user will enter their number on this after pairing? I'm going to assume this is what you mean.
There are a few problems, like for example the user may change their SIM card in which case their number may change. Can you tell me, does your BT device have some non-volatile storage to store the users phone number? What is the frequency of the file being uploaded to the server, is it once a day, once a week, once a month, etc?
As a strategy and to make your device as intelligent as possible II can outline the following:
Use case: Phone number retrieved from AT commands
Description: This use case is for the case whereby the number can be retrieved from the phone by AT commands
1. BT Device pairs with phone
2. BT Device tried to find out the phone number using AT commands, if this fails then go to UC: IMSI number retrieved
3. BT Device stores the phone number retrieved from the AT commands
4. When the BT device uploads the file to the server it also sends the phone number (which it has stored) thereby allowing you to call the user back
5. When the BT device is turned on, every time it must retrieve the phone number via AT commands and if its different to the one that it has stored then the BT device overwrites this old number with the new one in its storage.
Use case: IMSI number retrieved
Description: This use case is for the case whereby the phone number cannot be retrieved but the IMSI can be retrieved by AT commands. BT device has been paired.
1. Retrieve the IMSI via AT commands and store it in the BT device. If this fails then go to UC Identify phone number.
2. The BT device uses AT commands to send the BT device ID to the server, now the server has a mapping from the BT device ID to phone number.
3. When a file is uploaded, the BT device sends through its ID to the server as well so that you know which user to call back (as the server has the mapping from BT device ID to phone number).
4. Every time the BT device is turned on, it retrieves the (of course it first tries to retrieve the phone number) IMSI via AT commands and if its different then is assumes that the number has changed and resends the SMS from step 2.
Use case: Identify phone number
Description: This use case is for the case whereby the phone number and IMSI cannot be retrieved from the phone. The BT device is already paired
1. The phone sends an SMS with its BT device ID in the body to the server, the server then keeps a mapping from BT device ID to phone number.
2. When the BT device sends the file to the server it also sends the BT device ID thereby allowing you to call the user back.
Now the issue with this last use case is that the user may change their SIM card and phone number. To solve this you could either send an SMS after each file upload (dependent upon the frequency of uploads and how many users you have) or it could send an SMS periodically to ensure the phone number/BT ID mapping on the server is up to date.
For the strategy above to work, this means at a minimum is that your BT device can only work with phones that support retrieving their phone number via AT commands OR that the phone supports AT commands to send an SMS. I think that's fair enough as you already have the requirement that the phone must support DUN. As an aside to this, some of these rules could be specified in a configuration file which your BT device can download (assuming you have non-volatile storage) at least then you'd have the flexibility to update the rules for phone number identification if you needed.
