[Standards] UPDATED: XEP-0301 (In-Band Real Time Text) - Odd strategies

Edward Tie famtie at xs4all.nl
Tue Jul 10 15:58:06 UTC 2012


Op 10/07/2012 17:32, Mark Rejhon schreef:
> On Tue, Jul 10, 2012 at 2:58 AM, Gunnar Hellström 
> <gunnar.hellstrom at omnitor.se <mailto:gunnar.hellstrom at omnitor.se>> 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.*



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120710/5ffff1d2/attachment.html>


More information about the Standards mailing list