Thank you very much for your kind assistance. The specs you recommended has been very useful for me.
During my testings for multi-part messages, I have accidentally discover an "unusual behaviour" of SMS Server v3.2.2 I am using now. The issue in question as follow: - 1) Message: encoding 7bit, length exactly = 160 char. Perfect, no problem 2) Message: encoding 7bit, lenght exactly = 302 char. problem - message never got sent, db status field shows "Q" 3) Message: encoding 7bit, lenght exactly = 453 char. problem - message never got sent, db status field shows "Q" 4) Message: encoding 7bit, lenght exactly = 604 char. problem - message never got sent, db status field shows "Q" The problem appears to be happening in multiple of 151 chars, which is the max length for 7bit encoding as mention in the specs documentation, 3GPP 23.040. I am not sure if this issue is localised in SMS Server 3.2.2. Would you be able to shed some light whether the latest version 3.3.1. has the same issue? Regards On Nov 13, 3:44 am, Thanasis <[EMAIL PROTECTED]> wrote: > I think you should read the spec :) > > From the spec sheet (http://www.3gpp.org/ftp/Specs/archive/23_series/ > 23.040/23040-601.zip) > > <<< > > 9.2.3.24.8 Concatenated short messages, 16-bit reference number > > This facility is an enhanced variant of the Concatenated Short Message > facility (see clause 9.2.3.24.1). The enhancement is a 16-bit > reference number, instead of the short 8-bit reference number. The > larger reference number reduces the probability that two different > concatenated messages are mistakenly sent with identical reference > numbers to a receiver. Except for the size of the reference number > this facility is identical to the Concatenated Short Message facility > (see clause 9.2.3.24.1). > In the case of uncompressed 8 bit data, the maximum length of the > short message within the TP UD field is 133 (140 - 7) octets. > In the case of uncompressed GSM 7 bit default alphabet data, the > maximum length of the short message within the TP UD field is 151 (160 > - 9) characters. > In the case of 16 bit uncompressed USC2 data, the maximum length of > the short message within the TP UD field is 66 ((140 - 7)/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. > > > > The 3GPP 23.040 series is a very informative spec sheet if you want to > dig deeper. > > On Nov 12, 8:13 pm, nchin <[EMAIL PROTECTED]> wrote: > > > > > Sorry for the trouble, I am actually quite confused, hope you guys > > could help me: > > > So far this is what I understood > > 1) 7-bits encoding gives 160 chars per sms > > 2) 8-bits encoding gives 140 chars per sms > > 3) Unicode encoding gives 70 chars per sms > > > Can someone tell me, how to calculate the number of multi-parts sms > > for the three scenario above, please? Since I cannot simple divide > > into 160, 140 or 70 for all three scenario respectively because of the > > overhead. > > > Thanasis, you mentioned in your earlier reply that it is about 4 to 6 > > char, so what should I use to calculate? Kindly accept my apologies if > > my question sounds dumb. I really need to be precise to get the exact > > number of multi-part. > > > TIA > > > On Nov 11, 7:28 pm, Thanasis <[EMAIL PROTECTED]> wrote: > > > > Unicode/UCS2 is two-bytes per char! > > > Unicode max message length is 70 chars - you should take this into account > > > in your calculations. > > > > 2008/11/11 Aryo Sanjaya <[EMAIL PROTECTED]> > > > > > On Mon, Nov 10, 2008 at 12:35 AM, nchin <[EMAIL PROTECTED]> wrote: > > > > >> Aryo, thank you for your assistance. > > > > >> Correct me if I am wrong, based on your formula, if the encoding is > > > >> Unicode/UCS2, then the formula should be:- > > > >> if length(string) <= 140 the > > > >> sms_count = 1 > > > >> else > > > >> sms_count = floor( length(string) / (140-7) ) + 1 > > > >> endif > > > > >> Am I right? I will be grateful if you could help clarify. > > > > > Sorry for the late response. > > > > > I have no idea how concatenated SMS is implemented on Unicode. Sorry. > > > > > But I think the formula will be different, not just subtract it with 7 > > > > chars. > > > > > As Thanasis said, PDU will get 4-6 bytes per part as an information. > > > > Since > > > > Unicode has different character wide (8 bits instead of 7), so I think > > > > it > > > > will not take 7 chars as on 7-bits SMS. Maybe fewer. > > > > > It's only my opinion, without any references :) > > > > > -- > > > > Best Regards, > > > > > Aryo Sanjaya- Hide quoted text - > > > > - Show quoted text -- Hide quoted text - > > > - Show quoted text -- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SMSLib Users Group" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/SMSLib?hl=en -~----------~----~----~----~------~----~------~--~---
