1. SMPP 3.3 Implementation Note for Logica's Telepath 2600 state that "Telepath SMSC 2600 offers support for messages of up to 255 bytes in length. SMPP also supports a maximum of 255 characters of text in the submit_sm, submit_multi and deliver_sm PDUs.
However, each network variation is limited to a fixed maximum length, which may be further impacted by data coding scheme used, e.g. 7 bit, 8 bit etc. The SMSC depending on configuration may reject or truncate messages that exceed the network maximum. Note: The maximum message length prior to Telepath SMSC 2600 was 140 bytes." so even if you wanted to modify the code to be specific for SMPP 3.3 then the maximum you could support should be 255 (254 0 index). 2. Oded - also think you're right about the assumption that all messages with a UDH part are binary, as according to the standard both header+text and header+binary should be acceptable. "For binary or Unicode (UCS2) messages, the entire short_message field is formatted exactly as described for the TP-UD field in [1]. * For text messages with User Data Headers, the User Data Header part is encoded exactly as described for the TP-UD field in [1]. However the text part following the User Data Header should be encoded in the local platform character set (typically a variant of ASCII). This will be the same encoding as is used for pure text messages in SMPP." 3. Splitting messages over SMPP Dedy - you should follow the protocol standards which says that user applications external to SMPP should split large messages and set the UDH accordingly "SMPP can support handling of fragmented short messages using the User-Data-Header- Indicator service-element. In this way external applications (ESMEs) may implement message fragmentation and re-assembly, in conformance with the GSM03.40 specification, using SMPP and the GSM mobile network as submission and delivery interfaces. The message fragmentation and re-assembly must be conducted by the ESME application. Messages received by the SMSC as fragments of a longer message will be transported securely to the destination interface, with the UDHI intact." I think I'll be popping this document in the SMPP area of our website. Regards Alex http://www.skywire.co.uk/ ----- Original Message ----- From: Oded Arbel To: Dedy Sutanto ; [EMAIL PROTECTED] Sent: Tuesday, September 17, 2002 12:38 PM Subject: RE: Concatenation Problem in SMPP No, that's ok - I have it on my desk :-) ok - short_sm can be upto 254 octets, my mistake. it still not 1600 and still not compatible with other drivers. you should stick to the UDHI implementation and find out why you receive the messages as binary when it just have UDH set. my guess is that its a bug in the SMPP driver that assumes that any message with UDH in it is binary, I've seen similar stuff elsewhere. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. Who the fuck is General Failure? And why is he reading my harddisk? -----Original Message----- From: Dedy Sutanto [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 17, 2002 1:09 PM To: Oded Arbel; [EMAIL PROTECTED] Subject: RE: Concatenation Problem in SMPP Ok it is broke something. But I disagree with you about "SMPP standard clearly states that short_message may not be longer then 160 characters". I have SMPP 3.4 specification. And in SUBMIT_SM, it is mention that short_message is up to 254 octet. It means, we can send SM more than 160 via SMPP 3.4. I can send you this document (1,5 Mbytes) if you will Regards, -dedy- -----Original Message----- From: Oded Arbel [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 17, 2002 4:51 PM To: Dedy Sutanto; [EMAIL PROTECTED] Subject: RE: Concatenation Problem in SMPP If you've changed the behaviour of smsbox to solve a driver specific issue, in a non portable way - they heck yes : you broke something. your smsbox will probably not work with any other driver. nor with any other SMPP server except the comverse one, as IIRC the SMPP standard clearly states that short_message may not be longer then 160 characters. You're using a non compliant SMPP server, even if non-compliant in a good way, meaning - handles non-compliant clients. your "messages are received binary" is probably related to improer DCS setting. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. In /dev/null no one can hear you scream -----Original Message----- From: Dedy Sutanto [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 17, 2002 11:04 AM To: [EMAIL PROTECTED] Cc: Oded Arbel Subject: RE: Concatenation Problem in SMPP The problem is, when I send plain SMS (7-bit) with length more than 160 (240) and smsbox split it and add UDHI, SMSC send me 2 binary messages. I thought, it because the UDH. Then I did a dirty hack in smsbox.c. I change value MAX_SMS_OCTETS from 140 to 1600. And try sending other plain SMS more than 160. It's work! I test for logo and ringtones which more than 160 characters. And it's work too. I don't know if my dirty hack will broke something or not. I don't know either if MMS implementation in my SMSC differs. (I use Comverse SMSC) It seem, SMSC done the concatenation. Regards -dedy-
