Re: are these bugs when sending concatenated SMSs

Hi,

for 7bit (text message) kannel send 154 octets of text + 6 octets udh that  
give you 160 Octets together. SMPP doesn't pack because it's not necessary  
following the spec but SMSC packs then those.

Am 31.01.2007, 09:41 Uhr, schrieb Hillel <[email protected]>:

> Hi,
>
> I've been looking at the spec 03.40 and I've also tested and 154 is the  
> max
> amount of chars you can use before becoming another SMS.
>
> If I re-read the spec below with this information, can I assume Kannel is
> using compressed GSM Default alphabet 7 bit data and you always lose 6
> octets to give you 134 octets left which translates into 154 chars.?
> (If it was using uncompressed GSM Default 7 bit data then you would only
> have 153 chars per concatenated SMS.)
>
> Is my understanding correct?
>
> 9.2.3.24.1	Concatenated Short Messages
> This facility allows short messages to be concatenated to form a longer
> message.
> In the case of uncompressed 8?bit data, the maximum length of the short
> message within the TP?UD field is 134 (140?6) octets.
> In the case of uncompressed GSM Default 7 bit data, the maximum length of
> the short message within the TP?UD field is 153 (160?7) characters.
>
> In the case of 16 bit uncompressed USC2 data, the maximum length of the
> short message within the TP?UD field is 67 ((140?6)/2) characters. A UCS2
> character must not be split in the middle; if the length of the User Data
> Header is odd, the maximum length of the whole TP-UD field is 139 octets.
>
> In the case of compressed GSM Default alphabet 7 bit data, 8 bit data or
> UCS2 the maximum length of the compressed short message within the TP-UD
> field is 134 ( 140-6) octets including the Compression Header and
> Compression Footer, both or either of which may be present ( See  
> subclause
> 3.9).
>
> The maximum length of an uncompressed concatenated short message is 39015
> (255*153) default alphabet characters, 34170 (255*134) octets or 17085
> (255*67) UCS2 characters.
>
> Thanks for your great response.
>
> Rgds
>
>
>



-- 
Thanks,
Alex