Op 10/07/2012 17:32, Mark Rejhon schreef:
On Tue, Jul 10, 2012 at 2:58 AM, Gunnar Hellström
<[email protected] <mailto:[email protected]>> wrote:
Mark,
I see that you in this version have introduced a couple of "odd"
real-time text transmission strategies in sections 6.4.1 and
6.4.2, based on the 'reset' event.
http://xmpp.org/extensions/xep-0301.html#realtime_text_transmission_methodologies
Gunnar -- several are excellent suggestions.
An explanation at the beginning of 6.4 The transmission strategy in
6.4.1 and 6.4.2 is not recommended for messages bigger than
approximately SMS size, for mobile devices that want to write very
compact & simple implementations of real-time text that does not
require much processing or battery -- and they can take advantage of
stream compression to eliminate the redundancy disadvantage of message
resets. It was explained to me that it may actually use less
bandwidth and less CPU in certain situations. Even though it means a
disadvantage of losing key press intervals (the intervals demonstrated
at www.realjabber.org/anim/real_time_text_demo.html
<http://www.realjabber.org/anim/real_time_text_demo.html> ) which I
already mention.
I have found a information about larger sms :
Message size
Transmission of short messages between the SMSC and the handset is done
whenever using the Mobile Application Part
<http://en.wikipedia.org/wiki/Mobile_Application_Part> (MAP) of the SS7
<http://en.wikipedia.org/wiki/Signaling_System_7> protocol. Messages are
sent with the MAP MO- and MT-ForwardSM operations, whose payload length
is limited by the constraints of the signaling protocol to precisely 140
octets <http://en.wikipedia.org/wiki/Octet_%28computing%29> (140 octets
= 140 * 8 bits = 1120 bits). Short messages can be encoded using a
variety of alphabets: the default GSM 7-bit alphabet
<http://en.wikipedia.org/wiki/GSM_03.38>, the 8-bit
<http://en.wikipedia.org/wiki/Bit> data alphabet, and the 16-bit UCS-2
<http://en.wikipedia.org/wiki/UCS-2> alphabet.^[35]
<http://en.wikipedia.org/wiki/Short_Message_Service#cite_note-3GPP_23.038-34>
Depending on which alphabet the subscriber has configured in the
handset, this leads to the maximum individual short message sizes of 160
7-bit <http://en.wikipedia.org/wiki/Bit> characters, 140 8-bit
characters, or 70 16-bit characters. GSM 7-bit alphabet support is
mandatory for GSM handsets and network elements,^[35]
<http://en.wikipedia.org/wiki/Short_Message_Service#cite_note-3GPP_23.038-34>
but characters in languages such as Arabic, Chinese, Korean, Japanese or
Cyrillic alphabet languages (e.g. Russian, Serbian, Bulgarian, etc.)
must be encoded using the 16-bit UCS-2
<http://en.wikipedia.org/wiki/UCS-2> character encoding
<http://en.wikipedia.org/wiki/Character_encoding> (see Unicode
<http://en.wikipedia.org/wiki/Unicode>). Routing
<http://en.wikipedia.org/wiki/Routing> data and other metadata
<http://en.wikipedia.org/wiki/Metadata> is additional to the payload size.
*Larger content (concatenated SMS
<http://en.wikipedia.org/wiki/Concatenated_SMS>, multipart or segmented
SMS, or "long SMS") can be sent using multiple messages, in which case
each message will start with a user data header (UDH) containing
segmentation information. Since UDH is part of the payload, the number
of available characters per segment is lower: 153 for 7-bit encoding,
134 for 8-bit encoding and 67 for 16-bit encoding. The receiving handset
is then responsible for reassembling the message and presenting it to
the user as one long message. **While the standard theoretically permits
up to 255 segments,^[36]
<http://en.wikipedia.org/wiki/Short_Message_Service#cite_note-35> 6 to 8
segment messages are the practical maximum, and long messages are often
billed as equivalent to multiple SMS messages.*
