v3.2.2 is history - why are we discussing about it???. To answer your question, there were some problems in the message encoding, especially when the message length was near the multi-part limit.
The latest v3 library uses a new encoding package (contributed by Jeff Jongko) which is much more stable. 2008/11/13 nchin <[EMAIL PROTECTED]> > > 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 -~----------~----~----~----~------~----~------~--~---
