I am using smpp protocol to send Flash message. I am doing this to set data_coding to class 0:
dataCoding = ((dataCoding | 0x10) & 0xFC)
When this gets delivered it appears as:
Is there any way in smpp protocol using which I can make Class 0 Message appearing at top disapper?
Also, these messages get delivered to only a few phones. On some phones, they appear as normal messages. Is there anything else I should use, to make flash messages reliable and more friendly?
Regarding your first question on controlling the subject of the message. As Class 0 Flash messages are simply SMS's with just a different message class there is no such thing as a "subject". It is up to the mobile device to handle the immediate display of a flash message.
For the second question this could be for multiple reasons:
Mobile device was unable to receive the message due to being "out of range". In most cases mobile operators will adhere to the GSM spec and retry until they get confirmation from the mobile device but this is not always the case.
Mobile operator does not allow flash messages to be sent through to it's subscribers
Some mobile devices can disable the reception of flash messages
Some mobile devices do not have a mechanism to handle flash messages.
Without having more information it's hard to give you a concrete answer on the second part of the question.
Related
My problem is as follows:
I would like to make an application to list the sms conversation using C# and AT Command ... (not Android)
The Android/iOS smartphone will be connected by USB cable.
is it possible ?
any ways to help me
Provided the phone implements a serial USB interface that speaks AT commands (Communication Device Class (CDC) Abstract Control Model (ACM)), then yes this is possible.
The command to read SMS messages is AT+CMGR and it is standardized in the 3GPP specification 27.005. For reading1 SMS messages there no special handling other than the normal AT command response parsing (never use sleep/delay/etc).
The sms commands operates in one of two modes, Text mode (optional) or PDU mode (mandatory). Text mode is simpler but does not provide all the meta information that PDU mode does. Depending on the phone or what you want to display and parse you might be required to use PDU mode.
Parsing the hexadecimal binary response you get in PDU mode is very far from trivial, and you most certainly want to use a library for this rather than trying to write parse code yourself (at least when your experience is starting on not knowing about the relevant commands and not having read V.250, 27.007 and 27.005 before).
1For sending you must wait for `"\r\n> " before sending the payload, see the first part of this answer.
I have a technical issue that I can't resolve because the problem only happens on the other side of the planet that I'm on.
So I am hoping someone with a lot more Experience with these technologies can suggest an alternate approach or path to take in order to rectify it, or possibly right out "RECOGNIZE" the source of the problem.
THE SCENARIO :
I have developed an application for the Samsung Gear2 that sends SMS messages using its host companion android application.
In all tests I perform with the app pair, everything works as expected.
Messages are sent by the android device's SMS manager and received by the recipient no problem, even when adding and removing the leading 1.
10 and 11 digit numbers to and from the USA, with and without the leading + sign all pass.
However, when sending the apps to Samsung for review and testing, they keep having problems sending certain numbers. As far as I can tell the only thing different between the numbers that send and the numbers that fail is the fact that the first has a leading 0 and the second does not.
This would have to be coupled with the fact that they are testing this functionality
in a different Continent/Country than the 1 where my tests are being done(USA).
As my tests succeed to send and receive the messages regardless of whether
the number is a 10 digit version or 11 digit version of the same number.
Also discrepancies surfacing from the use of different Carriers (possibly Telecom in Asia) other than the one that I am testing with(Bell - USA)...
To be clear, I am simply composing messages via the Gear2 app and sending it to the android device via Samsung's Accessory Protocol which works flawlessly.
From there I use the basic implementation of the standard
Android's SMSManager
getDefault()
and
sendTextMessage(String destinationAddress, String scAddress, String
text, PendingIntent sentIntent, PendingIntent deliveryIntent)
with all null values exept the "destinationAddress","text",
and the "sentIntent".
THE QUESTION(s) : in order of most to least important
1. IS THERE a specific "routine" SMS app developers use to maximize the
success rate
of sent sms messages no matter what Country or Carrier the user sends the message from or to, and no matter if the entered number contains the leading exit and Country codes?
(ie: Adding or removing a plus(+) sign, per-examining the Locale
being used and adjusting the number accordingly using some sort of
"SMS Numbering Standard", Altering the Service Center Address / SMSC
Address (AT+CSCA), ect...)?
2. IS THERE some sort of information source detailing general "GOTCHAS" to look for
dependent upon the various Cell/SMS service providers/Carriers? (at least 4 that I know of).
3. Why would Android's SMSManger report "SMS Sent" if the message wasn't actually delivered.
NOTE: I realize that one can also listen for the "second" broadcast android sends
confirming that the message was "actually" received by the recipient, but that raises questions concerning how to rectify that situation, if it's at all rectifiable (at least from a programmatic perspective.)
4. Should my app, which is actually a Samsung Gear2 app integrated with an android app,
and merely delegates the responsibility of sending the messages to the android devices SMSManager, be held responsible for the message not being sent?
NOTE: I can't help but feel that Samsung is requiring me to handle
issues outside the scope and unrelated to the apps intended
functionality, Albeit , I do understand that at least part of the
issue has to fall back on me by Default, being the nature of the Gear2
apps dependance on the android device to complete the intended action
started by the Gear2 app, but how far must I go to ensure the standard
SMS abilities of a users android device beyond giving helpful feedback
as to what the underlying problem may be. I have to assume this
problem would exist using the device itself to compose the message
instead of the Gear2 app, given the exact same address/number .
5. Assuming that the app is being tested in Asia (South Korea, Samsung's Headquarters)... And assuming that the carrier being used to test SMS is SK Telecom
(Which I think is South Korea's top Carrier)...
Is it Mandatory to start all numbers with a zero in order to successfully send an SMS within the same Country? And if so is that the same in all Countries besides the USA and Canada(Which seem to work either way)?
6. Is this a common issue to deal with generally when developing sms applications, or can I single this particular situation out from the rest based on the unique variables introduced by Samsung's over diligent testing practices along with there unfamiliar
Telephony Service Providers and even more unfamiliar Geo-location/Country-code and numbering schemes.
THE PROBLEM *(only happens during Samsung testing) :
TEST 1:
Send SMS from stored contacts with number 010-6627-xxxx (11 digits)
Result:
SMS is reported by android's SMSManager as sent. The recipient
immediately receives SMS message.
Conclusion:
SMS delivery success.
TEST 2:
Send SMS from manually entering number 10-6627-xxxx (10 digits) (same number as previous without first 0)
Result:
SMS is reported by android's SMSManager as sent. However, the
recipient never receives SMS message.
Conclusion:
?
Unable to duplicate this problem (at least not in the USA) as both :
11 digit numbers (leading 1) AND 10 digit numbers
(no leading 1)
Successfully send the message as expected.
The problem only happens during device testing/certification by Samsung's app testing
department, and seemingly only when manually entering the destination address/number.
Stored Contacts (for some reason) always work.
After being denied certification of an otherwise "GOOD TO GO APPLICATION" 3 times by Samsung for issues UN-recreatable in my own testing environment I find myself turning the good folks at SOF with this "HAIL MARY PASS".
I do not change anything at all about the numbers that are sent to the SMSManager, But I'm wondering if maybe THAT'S the problem.
EXTRA INFO :
All devices used are using android 4.2 and higher.
My tests were all done using T-Mobile Galaxy phones and sometimes google/Gmail/GoogleVoice
sms/mms service From North Fla. USA.
ON A SIDE NOTE ABOUT SAMSUNG...
Samsung's testers are very sparse with the details of their testing enviroment including what may possibly be the issue from their standpoint which is unfortunate because I'm becoming certain that this issue is Trivial at best and probably easily fixable with a basic understanding of your own Country/Carriers methods for sending successful SMS messages.
It seems they are not even making an effort to enlighten me or TO make any neccesary
adjustments to their test numbers as any user would do in order to have a successful result.
ANY INSIGHT INTO THIS ISSUE WHATSOEVER WOULD BE IMMENSELY APPRECIATED!!!
Interesting question. I understand that the Samsung testing process can be quite rigorous.
From reading your info .. have you tried including that leading "0" yourself? E,g when a person manually enters 10 digits without a leading 0, you detect it and add this "0" . Also, how are this digits entered on a gear 2 device ? Do you implement your own keypad and ensure it captures the right digits ?
I guess that would be a starting point ..
V.
I am currently developing an android app and i want to send data message with audio file attached to it. One of the arguments of the sendDataMessage() methods is "destination port".
I know its the port i want to send the message via, but I am not sure what to put there, is there a default port for sending data messages? I have looked for it but every example I have seen uses different port. However, whichever port I use, I get Null PDU exception.
I am using HTC for running and testing the app btw.
Default is 8091. Most devices don't support port filtering very well, though:
SmsManager.sendDataMessage(..., onSpecificPort , ...,.. ) Is not Filtering SMS On Port Basis
Your null PDU is probably not because of a port selection problem, though.
For some work I'm doing, I want to have an emulated GSM modem which will communicate with an Android-x86 virtual machine over a Unix socket. The VM should see the emulator as a real modem and use it to send SMS (as the first pass of functionality).
So far, I've put something together which handles some AT commands and just replies "OK" to all the rest. For some commands, like "AT+CRSM", I just have a table of responses gathered from running the official Android emulator and looking at the radio log. For others, I maintain some state and construct answers; those commands include:
CFUN?
CPIN?
CGREG?
CGREG?
COPS?
CGREG=
CREG=
CPIN=
COPS=
CRSM=
CSMS=
CGSN
CIMI
CSQ
Android will boot, and send commands to my emulated modem, which answers, however it doesn't seem to be fully functional. Android doesn't detect any radio signal strength, for instance, just showing an "x" in the signal bar.
Does anyone know of a similar project, or just what AT commands are absolutely necessary to get some basic functionality?
Well, I'll answer another of my own questions, it's easier that way.
I ended up implementing an emulator which maintains a little bit of state, such as whether or not unsolicited CREG and CGREG messages are enabled, the network registration status & network name format (for the COPS command), and a message reference counter for SMS.
It supports the following commands:
CFUN?
CPIN?
CGREG?
CREG?
COPS?
CGREG=
CREG=
CPIN=
COPS=
CRSM=
CSMS=
CMGS=
CGSN
CIMI
CSQ
All other messages just get an "OK" response.
With the stock AOSP Android source running in an emulator with the "-radio unix:/tmp/phone" switch, I can send SMS messages and decode the binary PDUs into real messages. I will continue to add functionality so SMS messages can be injected back to Android, and hopefully open-source the code at some point.
I've got an app that lets users send sms messages. Works great when the message < 160 characters. After that, things work less-perfectly. Seems like there are a few options here:
Manually break the message up into multiple SMSs, send each part as a separate SMS.
Use the multi-part send SMS function (sendMultipartTextMessage()).
Send the message as an MMS message (sendDataMessage()?).
Here's my novice take on it:
1)
most well supported across carriers. Users may get mad that you just cost them N separate messages though, instead of converting to MMS or something.
2)
not sure if this is supported by different carriers, and read that once the message is greater than 3 * 160 chars in length, gets converted to MMS anyway by different SMS apps - maybe stay away from this altogether.
3)
not sure how to do this, and older phones might not support MMS. To send an MMS using the android SDK, do we just use the SmsManager.sendDataMessage() method?
Thanks
This is quite an old post but it's high up on Google when searching for Android multipart sms, so maybe it helps someone.
Regarding part 1 and 2, it's pretty much the same thing. To use sendMultipartTextMessage, you need to break up the long message into an ArrayList of Strings. It then sends as many SMS as needed. In short:
SmsManager sms = SmsManager.getDefault();
ArrayList<String> parts = sms.divideMessage(longMessage);
sms.sendMultipartTextMessage(phoneNumber, null, parts, null, null);
Part 3: MMS is not an option, as it has been pointed out. The charges and all.
seems to me that the first option is what most mobile phones do by default. sms messages by design can only send a certain amount of characters (160 probbaly), just inform the user that the message is too big and if he still wants to send it anyway (informing also how many sms would the total be).
as for MMS and multipart as you said not every carrier supports it, so they dont seem to be the best option.
EDIT: as for how does MMS work on android-sdk check this thread out: Android SDK MMS
I would suggest the usage of option 2 when you are working on Androids GSM based handsets.
GSM based Mobile device takes care of segmentation in which breaking the messages to multiparts for sending in performed and also assembling of the multipart messages in to one message on receipt.
If you have a method which takes care of sending text messages, than by default use the options of manager.divideMessage as it will work even if the message segments required are only 1 in number.
I dont think you should have any problem sending messages using option 2 and it will also ensure that the receiver receives the message as a single message.
Else we need to write your our own protocol stack where in you write reference number and number of messages for the receipient to understand and recreate the complete message; which is not very tough. We can use byte arrays with headers and the messages can be sent as base64 encoded.
Also I dont know much about the limits the carriers enforce on the number of segments in multipart message; based on my test I was able to send and receive 160*8 segments properly. Based on the GSM standards the segments can be upto 255 but that count might depend on the service provider implementation.