|
|||||||
| PREV NEXT | FRAMES NO FRAMES | ||||||
This appendix describes an adapter that uses the messaging API with the GSM Short Message Service.
The GSM SMS messages are defined in the GSM 03.40 standard [1]. The message consists of a fixed header and a field called TP-User-Data. The TP-User-Data field carries the payload of the short message and optional header information that is not part of the fixed header. This optional header information is contained in a field called User-Data-Header. The presence of optional header information in the TP-User-Data field is indicated by a separate field that is part of the fixed header.
The TP-User-Data can use different encodings depending on the type of the payload content. Possible encodings are a 7-bit alphabet defined in the GSM 03.38 standard, 8-bit binary data, or 16-bit UCS-2 alphabet.
The maximum length of the SMS protocol message payload depends on the encoding and whether there are optional headers present in the TP-User-Data field. If the optional header information specifies a port number, then the payload which fits into the SMS protocol message will be smaller. Typically, the message is displayed to the end user. However, this Java API supports the use of port numbers to specify a Java application as the message target.
The messages that the Java application sends can be too long to fit in a single SMS protocol message. In this case, the implementation MUST use the concatenation feature specified in sections 9.2.3.24.1 and 9.2.3.24.8 of the GSM 03.40 standard [1]. This feature can be used to split the message payload given to the Java API into multiple SMS protocol messages. Similarly, when receiving messages, the implementation MUST automatically concatenate the received SMS protocol messages and pass the fully reassembled payload to the application via the API.
The GSM 03.40 standard [1] specifies two mechanisms for the concatenation, specified in sections 9.2.3.24.1 and 9.2.3.24.8. They differ in the length of the reference number. For messages that are sent, the implementation can use either mechanism. For received messages, implementations MUST accept messages with both mechanisms.
Note: Depending on which mechanism is used for sending messages, the maximum length of the payload of a single SMS protocol message differs by one character/byte. For concatenation to work, regardless of which mechanism is used by the implementation, applications are recommended to assume the 16-bit reference number length when estimating how many SMS protocol messages it will take to send a given message. The lengths in Table A-1 below are calculated assuming the 16-bit reference number length.
Implementations of this API MUST support at least 3 SMS protocol
messages to be received and concatenated together. Similarly, for
sending, messages that can be sent with up to 3 SMS protocol messages
MUST be supported. Depending on the implementation, these limits may be
higher. However, applications are advised not to send messages that
will take up more than 3 SMS protocol messages, unless they have reason
to assume that the recipient will be able to handle a larger number.
The MessageConnection.numberOfSegments method allows the application to check how many SMS protocol messages a given message will use when sent.
Table A-1: Number of SMS protocol messages needed for different payload lengths
Table A-1 assumes for the GSM 7-bit alphabet that only characters that can be encoded with a single septet are used. If a character that encodes into two septets (using the escape code to the extension table) is used, it counts as two characters in this length calculation.
Note: the values in Table A-1 include a concatenation header in all messages, when the message can not be sent in a single SMS protocol message.
Character Mapping Table
The GSM 7-bit characters that use the escape code for a two septet combination are represented in this table with the hexadecimal representations of the two septets separately. In the encoded messages, the septets are encoded together with no extra alignment to octet boundaries.
The syntax of the URL connection strings that specify the address are described in Table A-2.
Table A-2: Connection Strings for Message Addresses
Examples of valid URL connection strings are:
When this adapter is used and the Connector.open() method is passed a URL with this syntax, it MUST return an instance implementing the javax.wireless.messaging.MessageConnection interface.
In this URL connection string, the MSISDN part identifies the recipient phone number and the port number part of the application port number address as specified in the GSM 3.40 SMS specification [1] (sections 9.2.3.24.3 and 9.2.3.24.4). The same mechanism is used, for example, for the WAP WDP messages.
When the port number is present in the address, the TP-User-Data of the SMS MUST contain a User-Data-Header with the Application port addressing scheme information element.
When the recipient address does not contain a port number, the TP-User-Data MUST NOT contain the Application port addressing header. Java applications cannot receive this kind of message, but it will be handled as usual in the recipient device; for example, text messages will be displayed to the end user.
Messages can be sent using this API via client or server type MessageConnections. When a message identifying a port number is sent from a server type MessageConnection, the originating port number in the message is set to the port number of the MessageConnection. This allows the recipient to send a response to the message that will be received by this MessageConnection.
However, when a client type MessageConnection
is used for sending a message with a port number, the originating port
number is set to an implementation-specific value and any possible
messages received to this port number are not delivered to the MessageConnection.
Thus, only the server mode MessageConnections
can be used for receiving messages. Any messages to which the other
party is expected to respond should be sent using the appropriate
server mode MessageConnection.
When SMS messages are received by an application, they are removed from the SIM/ME memory where they may have been stored.
If the message information MUST be stored more persistently, then the application is responsible for saving it. For example, the application could could save the message information by using the RMS facility of the MIDP API or any other available mechanism.
The GSM SMS protocol does not guarantee to preserve the ordering when
multiple messages are sent. When a large message is split into multiple
GSM SMS sections as specified in A.1.2, ordering is handled correctly
when they are automatically concatenated back into a single Message object. If the application sends multiple Messages
to the same recipient, they might not be delivered in the correct
order. The application must be written so that it is able to deal with
this issue appropriately. However, even when the ordering may change
during the delivery in the network, the implementation MUST guarantee
that the messages are delivered to the application in the same order as
they were received by the implementation of the recipient terminal.
Applications might need to obtain the Short Message Service Center (SMSC) address to decide which recipient number to use. For example, the application might need to do this because it is using service numbers for application servers which might not be consistent in all networks and SMSCs.
The SMSC address used for sending the messages MUST be made available using System.getProperty with the property name described in Table A-3.
Table A-3: Property Name and Description for SMSC Addresses
The receiving application in a device is identified with the port number included in the message. When opening the server mode MessageConnection, the application specifies the port number that it will use for receiving messages.
The first application to allocate a given port number will get it. If
other applications try to allocate the same port number while it is
being used by the first application, an IOException will be thrown when
they attempt to open the MessageConnection.
The same rule applies if a port number is being used by a system
application in the device. In this case, the Java applications will not
be able to use that port number.
As specified in the GSM 03.40 standard [1], the port numbers are split into ranges. The IANA (Internet Assigned Numbers Authority) controls one of the ranges. If an application author wants to ensure that an application can always use a specific port number value, then it can be registered with IANA. Otherwise, the author can pick a number at random from the freely usable range and hope that the same number is not used by another application that might be installed in the same device. This is exactly the same way that port numbers are currently used with TCP and UDP in the Internet.
SMS messages can be sent using the TextMessage or the BinaryMessage
message type of the API. The encodings used in the SMS protocol are
defined in the GSM 03.38 standard (Part 4 SMS Data Coding Scheme) [2].
When the application uses the TextMessage
type, the TP-Data-Coding-Scheme in the SMS MUST indicate the GSM
default 7-bit alphabet or UCS-2. The TP-User-Data MUST be encoded
appropriately using the chosen alphabet. The 7-bit alphabet MUST be
used for encoding if the String that is given by the application only
contains characters that are present in the GSM 7-bit alphabet. If the
String given by the application contains at least one character that is
not present in the GSM 7-bit alphabet, the UCS-2 encoding MUST be used.
When the application uses the BinaryMessage, the TP-Data-Coding-Scheme in the SMS MUST indicate 8-bit data.
The application is responsible for ensuring that the message payload
fits in an SMS message when encoded as defined in this specification.
If the application tries to send a message with a payload that is too
long, the MessageConnection.send() method will throw an IllegalArgumentException
and the message will not be sent. This specification contains the
information that applications need to determine the maximum payload for
the message type they are trying to send.
All messages sent via this API MUST be sent as Class 1 messages GSM 3.40 SMS specification [1], Section 9.2.3.9 "TP-Protocol-Identifier".
For security reasons, Java applications are not allowed to send SMS
messages to the port numbers listed in Table A-4. Implementations MUST
throw a SecurityException in the MessageConnection.send() method if an application tries to send a message to any of these port numbers.
Table A-4: Port Numbers Restricted to SMS Messages
|
|||||||
| PREV NEXT | FRAMES NO FRAMES | ||||||