According to 3GPP 23.040 section 3.2.9 and annex D, "Reply Path specified in the present document provides a way of both requesting and indicating a service center's commitment to deliver a reply from the replying MS to the originating SME." For receiving a SMS-DELIVER message, TP-RP is currently neither supported in GsmPDUHelper.readMessage(), nor stored, fetched as reference in replying a SMS. Besides, SMSC address must therefore become a optional parameter of sendSMS(), null for default SMSC address. For sending a SMS-SUBMIT, it seems Android never request TP-RP(see frameworks/base/telephony/java/com/android/internal/telephony/gsm/SmsMessage.java, getSubmitPduHead()).

This issue will introduce yet another two fields, reply_path_present and original_smsc, in received SMS database. The reply procedures defined in 3GPP 23.040 Annex D is: 1) originating SME submit a SMS-SUBMIT pdu with TP-RP field set to 1 2) originating SMSC supports reply path requesting and set TP-RP field in SMS-DELIVER pdu 3) destination SME save TP-RP field and originating SMSC address along with the message 4) destination SME reply the message with TP-DA set to originating SME address and outgoing SMSC address with originating SMSC address

I see two different problems here: 1. Being able to specify the SMSC when calling send() if we don't want to use the default one. By the way, do you have any idea why that would be useful? 2. Reply-path issue... but I did not really understood what you meant...

(In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #2) > I see two different problems here: > 1. Being able to specify the SMSC when calling send() if we don't want to > use the default one. Yep, that's the way to implement it. > By the way, do you have any idea why that would be useful? For example, reverse-charging. An originating MS provides some free service that requires its subscribers to reply a certain message to deal. > 2. Reply-path issue... but I did not really understood what you meant... In order to send a reply to originating SMSC, app must know there exists a reply path for the message thread. So the very first message of the thread stored in sms database must have a field that stores TP-RP(a boolean value) and originating SMSC address. If a app found the TP-RP field was set to true and its originating SMSC address is available, it calls: sendSMS(smscAddr, number, body, requestId, processId); Or, if this reply path does not exist, it calls: sendSMS(null, number, body, requestId, processId); So, two new database fields and additional parameter(s) to saveReceivedMessage() and sendSMS() might be required to implement this feature.

(In reply to Vicamo Yang [:vicamo] from comment #3) > (In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #2) > > By the way, do you have any idea why that would be useful? > > For example, reverse-charging. An originating MS provides some free service > that requires its subscribers to reply a certain message to deal. Sorry, I don't get it. What MS means? > > 2. Reply-path issue... but I did not really understood what you meant... > > In order to send a reply to originating SMSC, app must know there exists a > reply path for the message thread. So the very first message of the thread > stored in sms database must have a field that stores TP-RP(a boolean value) > and originating SMSC address. If a app found the TP-RP field was set to true > and its originating SMSC address is available, it calls: Ok. But again why is that needed?

(In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #4) > (In reply to Vicamo Yang [:vicamo] from comment #3) > > (In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #2) > > > By the way, do you have any idea why that would be useful? > > > > For example, reverse-charging. An originating MS provides some free service > > that requires its subscribers to reply a certain message to deal. > > Sorry, I don't get it. What MS means? > Mobile station, could be any mobile devices inclusive of cellular phones. You don't have to say sorry, there is even a SPEC for these abbreviations! (3GPP TR 21.905 "Vocabulary for 3GPP Specifications"). > > > 2. Reply-path issue... but I did not really understood what you meant... > > > > In order to send a reply to originating SMSC, app must know there exists a > > reply path for the message thread. So the very first message of the thread > > stored in sms database must have a field that stores TP-RP(a boolean value) > > and originating SMSC address. If a app found the TP-RP field was set to true > > and its originating SMSC address is available, it calls: > > Ok. But again why is that needed? Er ... that's part of the specification, and someone, maybe rare, but might rely on it. And why that would be usefull? An example is reverse-charging. And there is not only one standard for every SMSC. Some might support a certain set of features, and others don't. It's possible that a MS might want to specify a reply path to bind a specific SMSC for further messages.

I have to say that is unfortunately not really clear to me. What you require is to provide a new argument to send() method that will allow specifying a SMSC. Also, you would like to add SMSC number and if there is a reply-path in SmsMessage so apps will be able to know if there is a reply path, right?

(In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #6) > I have to say that is unfortunately not really clear to me. In fact, you've correctly described this issue below. > What you require is to provide a new argument to send() method that will > allow specifying a SMSC. This is requirement #1. send(SMSC, number, body, requestId, processId). Just what I've said in comment #3. > Also, you would like to add SMSC number and if there is a reply-path in > SmsMessage. This is requirement #2: "two new database fields (`SMSC` and `ReplyPathPresent`)" as mentioned in comment #3. This also implies two additional parameters in saveReceivedMessage(). We might omit `ReplyPathPresent` and store originating SMSC address alone. If the SMSC field is not null, it means a reply path request exists. > so apps will be able to know if there is a reply path, right? Yes. This will need a patch in gaia sms app, whose source repository is now hosted on github.

First off, we shouldn't add functionality just because it's in the GSM specification. That said, if this is something that we think users want to use, for example because it's functionality that's in other SMS apps on other platforms, then I agree we should do it. Is the idea that we for each received message store a "reply path" so that if the user replies to a message we can automatically provide these new parameters? I.e. no new UI would be needed? Or is the idea that when you are sending a textmessage there could be a second optional textbox where the user would type the SMSC number? I don't know nearly enough about GSM to have an opinion here. I just want to make sure that we're adding functionality because it's requested by users, not because we try to implement every feature of the GSM spec.

(In reply to Jonas Sicking (:sicking) from comment #8) > First off, we shouldn't add functionality just because it's in the GSM > specification. There are also EMS(Enhanced Message Service), TP-VP(Validity Period), E-Mail internetworking, SMS compression, 8bit data coding scheme listed in SMS specification feature set that I did not report them as future tasks. > That said, if this is something that we think users want to use, for example > because it's functionality that's in other SMS apps on other platforms, then > I agree we should do it. I agree. Bugs I open till now are originated from comparison of features listed in SMS spec and those supported by Android aosp. Android doesn't support EMS, TP-VP, SMS compression and has only partial support of E-mail internetworking by now. EMS enables a much more fancy message experience. It may include animation, text style, pictures, almost what you may expect in MMS. However, it's not implemented in Android, and the way to implement it may alter a lot of parts that we had for simple text messages. E-Mail internetworking is a feature that may be provided by corporation email hosting service providers. They forward important emails as SMS to specific employees, i.e. IT specialists. This feature is relatively simple. SMS compression, not implemented by Android. 8bit coding scheme, receiving is not implemented by Android, but it's possible for a higher layer application to receive messages of 8bit coding scheme through SmsMessage.getPdu(). Outgoing is supported via SmsManager.sendDataMessage() in Android. TP-VP exists in outgoing SMS-SUBMIT messages only. Not implemented in Android. Bug 736706 USIM downloading is an important feature for many carriers to implement their services. Ringtone downloading, and many other value-added services relies on it. Bug 736708 Replace Message Types will be part of bug 736710 Message Waiting Indication, bug 736713 Enhanced Voice Message Information. > Is the idea that we for each received message store a "reply path" so that > if the user replies to a message we can automatically provide these new > parameters? I.e. no new UI would be needed? AFAIK, no new UI is needed, but an app must have the information about originating SMSC, ReplyPathPresent, and therefore results in interface change in SmsMessage object. > Or is the idea that when you are sending a textmessage there could be a > second optional textbox where the user would type the SMSC number? No, the SMSC address to be filled is the originating SMSC address of the first message in the thread. It's directly fetched from SMS database. > I don't know nearly enough about GSM to have an opinion here. Yep, no one does. At least I don't, either. So I shall reply your questions as possible as I can. That's nothing but a feature listed on SMS spec. We can decide whether or not should B2G implement it. > I just want to make sure that we're adding functionality because it's > requested by users, not because we try to implement every feature of the > GSM spec. Agree. Marking this issue as WON'T IMPLEMENT is also an option.

Please this into backlog.

Firefox OS is not being worked on